Содержание к диссертации
Введение
Глава 1. Анализ основных аспектов проектирования систем управления сложными технологическими объектами 10
1.1. Задачи и принципы проектирования СУ сложными ТО 10
1.2. Формализация задачи проектирования СУ сложными ТО 15
1.3. Особенности и основные задачи автоматизации проектирования СУ сложными ТО 21
1.4. Основные выводы и постановка задачи исследования 25
Глава 2. Исследование методологии и разработка специального алгоритмического обеспечения управления процессом проектирования СУ сложными ТО 27
2.1. Проектирование СУ сложными ТО, как объекта системного анализа 27
2.2. Методологические аспекты оптимального проектирования СУ сложными ТО с использованием эволюционной стратегии синтеза 36
2.3. Разработка методологии управления процессом проектирования СУ сложными ТО 55
2.4. Разработка специального алгоритмического обеспечения управления процессом проектирования 75
2.5. Анализ особенностей и реальных возможностей применения ВРМ-систем для управления процессом проектирования СУ ТО в рамках САПР 82
2.6. Основные выводы по главе 2 87
Глава 3. Разработка и реализация программного комплекса ук-01 автоматизированного управления процессом проектирования в рамках САПР СУ сложными ТО 88
3.1. Формирование общих требований и выбор методологии разработки комплекса УК-01 .88
3.2. Разработка общей структуры и архитектуры программного обеспечения комплекса УК-01 98
3.3. Основные решения по разработке информационного обеспечения, пользовательских интерфейсов и общего алгоритма функционирования комплекса УК-01 113
3.4. Основные выводы по главе 3 127
Глава 4. Анализ эффективности промышленного применения программного комплекса УК-01 129
4.1. Оценка эффективности промышленного использования 129
4.2. Внедрения результатов исследования в промышленности 133
Заключение 134
Список сокращений и условных обозначений
- Формализация задачи проектирования СУ сложными ТО
- Методологические аспекты оптимального проектирования СУ сложными ТО с использованием эволюционной стратегии синтеза
- Разработка общей структуры и архитектуры программного обеспечения комплекса УК-01
- Внедрения результатов исследования в промышленности
Введение к работе
Актуальность темы исследования и степень ее разработанности. Основной проблемой проектирования современных систем управления (СУ) сложными технологическими объектами (ТО) является создание методов, рассчитанных на использование ЭВМ и принципов системного анализа. Системный подход позволяет выделять основные подсистемы исследуемого объекта, формализовать задачи, цели и функции этих подсистем и механизмы связей между ними, разрабатывать альтернативные структуры СУ и намечать последовательность действий по выбору оптимальных вариантов по реализации проектных решений и оценке результатов их использования. Все это определяет необходимость использования новых принципов проектирования и внедрение нового инструментария - системы автоматизированного проектирования (САПР), обеспечивающей эффективную одновременную работу большого количества пользователей, а управление процессом проектирования является задачей, решение которой осуществляется постоянно при условии непрерывной работы коллектива разработчиков СУ конкретными ТО. Процесс в этом случае характеризуется динамическими изменениями, происходящими под воздействием внутренней и внешней среды в различные отрезки времени.
Проектирование с использованием средств автоматизации предполагает наличие управляющего комплекса (УК), отвечающего за соблюдение установленного порядка ведения технологического процесса проектирования. В зависимости от конкретной многопользовательской системы проектирования УК может выполнять различные функции, но при этом является неотъемлемой частью системы.
Своевременность и актуальность решаемых в настоящей работе проблем заключается в том, что в ней поставлена и решена задача системного исследования и выбора метода, разработки алгоритмов и программного комплекса автоматизированного управления процессом проектирования СУ сложными ТО, обеспечивающего параллельный инжиниринг, контроль версий рабочих данных и хода проектирования, реализацию одновременной разработки нескольких независимых проектов и многое другое.
Вопросам проектирования СУ сложными ТО посвящены работы авторов: Арунянца Г.Г., Ланцова В.Н., Норенкова И.П., Рутковского А.Л., Свечинского В.Б., Смилянского Г.Л., Солодовникова В.В., Шестихина О.Ф., Govind R., Morari М., Powers G.I., Stephanopoulos G., Wilson I.D. и др. Вопросам создания систем обработки информации посвящены работы авторов: Аракелян СМ., Зайцев И.Д., Костров А.В., Кравченко Т.К., Краснощеков П.С, Окунев Ю.Б., Садыков С.С, Телков Ю.К. и др.
Объектом исследования являются процессы и методология проектирования систем управления сложными технологическими объектами.
Предметом исследования являются методы и механизмы решения проблемы автоматизированного управления процессом проектирования СУ сложными ТО, ориентированного на условия коллективной работы специалистов-проектировщиков и обеспечения одновременной разработки нескольких независимых проектов.
Цели и задачи. Целью настоящей работы является разработка алгоритмов и программного комплекса, повышающих эффективность автоматизированного управления процессом проектирования СУ сложными ТО в условиях одновременной разработки нескольких независимых проектов.
Для достижения поставленной цели необходимо решить следующие задачи:
1. Системный анализ основных принципов, особенностей проектирования СУ сложными ТО и основных проблем его автоматизации; исследование и постановка задачи разработки системы автоматизированного управления процессом проектирования СУ сложными ТО.
-
Исследование методологической основы управления процессом оптимального проектирования СУ сложными ТО с использованием эволюционной стратегии синтеза и формирование принципов эффективного взаимодействия средств САПР СУ сложными ТО в условиях ее развития.
-
Исследование и выбор метода, разработка специального алгоритмического обеспечения автоматизированного управления процессом проектирования СУ сложными ТО.
-
Анализ особенностей и реальных возможностей применения ВРМ-систем для управления процессом проектирования СУ ТО. Анализ и выбор методов и средств разработки специального программного обеспечения для автоматизированной системы управления процессом проектирования СУ ТО.
-
Разработка структуры средств, информационного и специального программного обеспечения комплекса УК-01 автоматизированного управления процессом проектирования СУ сложными ТО.
-
Выбор метода и анализ эффективности функционирования разработанного программного комплекса УК-01 автоматизированного управления процессом проектирования СУ сложными ТО.
Научная новизна работы:
-
По результатам проведенных системных исследований выполнена декомпозиция процесса проектирования СУ сложными ТО на взаимосвязанные по конечным результатам укрупненные этапы (задачи), соответствующие профессиональным группам проектировщиков, позволившая упростить постановку и решение задачи управления процессом проектирования.
-
Разработаны и реализованы машинные алгоритмы автоматизированного управления (планирования, контроля, учета и принятия решений) процессом проектирования СУ сложными ТО в условиях одновременной разработки нескольких независимых проектов в соответствии с выбранным методом ситуационного управления.
-
По результатам анализа реальных возможностей применения ВРМ-систем для управления процессом проектирования СУ ТО и выбора методологии программирования разработана структура средств, информационное и специальное программное обеспечение комплекса УК-01 автоматизированного управления процессом проектирования СУ сложными ТО и алгоритмы его функционирования.
Теоретическая и практическая значимость работы:
-
Предложенный подход к организации процесса проектирования СУ сложными ТО с использованием результатов его декомпозиции на взаимосвязанные по конечным результатам укрупненные этапы (задачи), соответствующие профессиональным группам проектировщиков, упрощает постановку и решение задачи управления.
-
Разработанные алгоритмы принятия решений повышают степень автоматизации процесса управления проектированием СУ ТО и легко реализуются в рамках разработанного программного комплекса УК-01.
-
Разработанный и реализованный программный комплекс УК-01, ориентированный на использование в рамках специализированных проектных организаций, обеспечивает повышение эффективности процесса проектирования СУ сложными ТО в условиях одновременной разработки нескольких независимых проектов.
-
Разработанный программный комплекс УК-01 принят к использованию в ООО «МЦЭ-Инжиниринг» (г. Москва), 000 «КИТ» (г. Калининград), НПК
«Югцветметавтоматика» (г. Владикавказ). Экономический эффект от внедрения разработки для 1 организации в среднем составляет 1 680,0 т. руб. в год.
5. Отдельные теоретические положения, а также алгоритмы и машинные программы, представленные в диссертационной работе, используются в учебном процессе в ФГБОУ ВПО «Калининградский государственный технический университет (КГТУ)» при подготовке специалистов в области проектирования СУ ТО.
Методология и методы исследования. Проводимые исследования базировались на положениях технической кибернетики, методах синтеза и анализа СУ технологическими объектами, методах и приемах исследования сложных технологических объектов: системный анализ, математическое моделирование; совокупность методов и приемов анализа и обработки информации: монографический, сравнительный, динамический, группировок, расчетно-конструктивный, индексный.
Положения, выносимые на защиту: 1. Результаты проведенного системный анализ основных принципов, особенностей проектирования СУ сложными ТО и основных проблем его автоматизации; поставленная задача разработки системы автоматизированного управления процессом проектирования СУ сложными ТО и предложенные принципы эффективного взаимодействия средств проектирования СУ ТО в условиях ее эволюционного развития.
-
Подход к организации процесса проектирования СУ сложными ТО с использованием результатов его декомпозиции на взаимосвязанные по конечным результатам укрупненные этапы (задачи), соответствующие профессиональным группам проектировщиков, упрощающий постановку и решение задачи управления.
-
Разработанные алгоритмы принятия решений, реализующие задачи ситуационного управления процессом проектирования СУ сложными ТО, повышающие степень его автоматизации.
4. Разработанный и реализованный программный комплекс УК-01,
ориентированный на использование в рамках специализированных проектных
организаций, обеспечивающий повышение эффективности процесса проектирования
СУ сложными ТО в условиях одновременной разработки нескольких независимых
проектов.
5. Результаты практического применения разработанного программного
комплекса УК-01 при решении различных задач проектирования СУ ТО.
Степень достоверности и апробация результатов. Основные полученные результаты представлены в виде алгоритмов, функциональных, структурных и вычислительных схем, программных кодов. Научные положения, выводы и рекомендации подтверждается результатами экспериментальных исследований; результатами вычислительных экспериментов; соответствием теоретических и экспериментальных исследований; работоспособностью предложенных методов, алгоритмов и разработанного программного комплекса УК-01.
Основные результаты проведенных в диссертации исследований были представлены и обсуждены на: VIII Юбилейной Международной научной конференции «Инновации в науке и образовании - 2010» (КГТУ). - Калининград, октябрь, 2010; Международной научной конференции «Инновации в науке и образовании - 2011» (КГТУ).- Калининград, октябрь, 2011; Международной научной конференции «Инновации в науке и образовании - 2012» (КГТУ).- Калининград, октябрь, 2012; Международная заочная научно-практическая конференция «Актуальные проблемы развития науки и образования».- Москва, апрель, 2013; Международной научной конференции «Инновации в науке и образовании - 2013»
(КГТУ).- Калининград, сентябрь, 2013; научно-технических конференциях профессорско-преподавательского состава, научных работников и аспирантов КГТУ в 2010-2013 гг.
Основные научные положения, теоретические выводы и рекомендации, содержащиеся в главах 2...4 диссертационной работы, получены автором самостоятельно. Результаты исследований, приведенные в главе 1, получены автором в соавторстве.
По теме диссертационных исследований опубликовано 12 печатных работ, в том числе 5 научных статей в изданиях, рекомендованных ВАК.
Диссертация состоит из введения, четырех глав, заключения, списка сокращений и литературы из 193 наименований. Общий объем диссертации 216 страниц, в том числе 150 страниц основноготекста, 54 рисунков, 17 таблиц и 5 приложений.
Формализация задачи проектирования СУ сложными ТО
Одной из основных задач «формирования облика» является генерирование (на уровне конструктивных параметров) множества альтернативных вариантов проектируемой системы, учитывающего, с одной стороны, возможности «внутреннего проектирования» и, с другой стороны - удовлетворяющего (в рамках этих возможностей) требованиям «внешнего проектирования». Фактически, на этапе «формирование облика» строится корректное в вышеупомянутом смысле множество вариантов системы, среди которых следует искать вариант, обеспечивающий достижение целей, поставленных «внешним проектированием». Следует отметить важность этого этапа при проектировании сложных систем, в частности, СУ многомерных объектов.
Изложенный подход к разбиению процесса проектирования на этапы представляется эффективным и в равной мере может быть отнесен к процессу проектирования всех иерархических уровней СУ. При этом результаты проектирования вышестоящего уровня являются исходными для проектирования примыкающего нижестоящего уровня иерархии СУ.
Одним из центральных моментов при проектировании СУ сложными ТО на этапах научных исследований и реализации технических проектов сегодня становится развитие системного подхода (системной методологии), заключающегося в изучении системы и её поведения в целом как единого объекта, выполняющего определенную функцию в конкретных условиях.
Основой решения задач проектирования СУ ТО является синтез, анализ и оптимизация [117]. Значительное место в процессе проектирования СУ ТО занимает .математическое моделирование [25]. Под математической моделью понимается такая абстрактная система. которая, отображая или воспроизводя объект исследования, способна замещать его так, что её изучение дает необходимую информацию об этом объекте.
В классической теории автоматического регулирования использовались модели вида [117]: y{S) = u(s)g(s) + d(S)gd(s), (1.4) где y{s), w(j), d(s) - преобразования Лапласа выхода ,у(/), управления »(/) и контролируемого возмущения d[t), a g[s) и gj\S) - передаточные функции по управлению и по возмущению соответственно. Однако для многих процессов необходимо использовать значительно более сложные модели. Выбор типа модели и её построение является моментом творческим и исключительно важным. Модель должна отражать основные черты процесса, быть чувствительной к характеристикам, определяющим ход процесса, и в то же время не быть чрезвычайно сложной и загроможденной второстепенными, малосущественными для анализа параметрами. Необходимость математического моделирования при разработке СУ сложными ТО обусловлена возможностью использования моделей для анализа статических и динамических характеристик объекта управления, выбора структуры и параметров СУ, формирования критериев оптимальности и ограничений, решения задач прогнозирования и оценки точности. Особенно это важно для вновь разрабатываемых процессов, где модели могут служить для одновременного создания ТО и СУ [160]. Поскольку модель является только приближенным представлением реального объекта, решение вопроса о необходимой степени её соответствия (подобия) объекту должно быть связано с требованиями к СУ, рассматриваемой на её основе [19].
Значительное место в процессе проектирования занимает оптимизации характеристик исследуемых систем, устройств, элементов. Существенно, что при этом возникают задачи оптимизации как количественных, так и качественных характеристик. Классификация математических методов оптимизации и их сравнительный анализ приведены в работе [144. Необходимо отметить, что современный аппарат оптимального математического программирования не дает готовых рецептов для решения всех задач оптимального проектирования. Его эффективное использование требует изобретательности и свободного обращения с вычислительной техникой. При проведении массовых расчетов, присущих процессу проектирования, вопрос о выборе рационального алгоритма оптимизации является сложным и комплексным [50].
Процесс принятия решения при проектировании СУ, особенно для сложных ТО, заключается в сопоставлении нескольких альтернатив достижения поставленной цели и выборе наилучшей из них. Формально задача принятия решения сводится к оптимизации целевой функции по независимым параметрам, определяющим характеристики системы. Учитывая, что некоторые характеристики проектируемых СУ (например, надежность, стоимость и др.) обычно находятся в противоречии, при принятии решения проектировщик сталкивается с необходимостью компромиссного выбора или, иными словами, с поиском условного оптимума.
Широкое применение вычислительной техники и строгих математических методов в проектировании дает возможность не только значительно повысить эффективность и скорость решения ряда проектных задач, обоснованно принимать решение по прогнозу, но и снизить стоимость проектно-сметных работ за счет резкого уменьшения числа корректировок проектов. Это дает возможность уделять большое внимание первой стадии проектирования - разработке технико-экономического обоснования (ТЭО) и, в частности, более глубокой проработке и широкому представлению предлагаемых технических решений. Вопрос принятия проектного решения по локальным задачам связан с морфологическим подходом [25], дающим возможность выявить иерархию принятия решения на основе анализа технологической схемы проектирования, характер постановки задач проектирования и их взаимосвязей. При возможности формализации задачи определяется характер взаимосвязи её параметров, вид функции, выбирается математический метод решения такой задачи и т.д. При невозможности формализации для определения решения задачи используются: метод экспертных оценок [61]; матрицы и таблицы решений, деревья решений [85]; меюды, основанные на использовании лингвистических переменных [60].
Рассматривая основные проблемы и трудности применения современной теории оптимального управления для решения проблем проектирования СУ сложными технологическими объектами, можно сказать, что одним из действенных средств их устранения является скорейшее развитие понятия сложности и принципа сложности [29, 39-41].
Приведенный анализ общих методологических аспектов проектирования показывает, что задачи разработки сложных систем, какими, в частности, являются СУ сложными ТО, можно отнести к задачам, эффективное решение которых не може г быть осуществлено без применения системных методов анализа, глубоких исследований статических и динамических свойств систем, изучения внешних связей системы и взаимосвязей её элементов. 1.2. Формализация задачи проектирования СУ сложными ТО
Прежде чем рассматривать вопросы, связанные с рассмотрением основных проблем автоматизации проектирования СУ ТО, целесообразно рассмотреть сам процесс проектирования как стратификацию или иерархию решений, которую удобно изобразить в виде дерева с разветвлениями (рисунок АЛ) [55].
Принимая точку 0 за этап формулировки проблемы, варианты ее решения можно представить отрезками а;, а?, аз и т.д. Каждому варианту соответствует несколько проблем. обозначенных узлами W\i, Wn, W21, W22, W23, W31, W32, W33 и т.д. Поэтому очевидно, чт принятие варианта at требует решения подпроблем Wu, W12, принятие варианта ci2 -подпроблем })г21, W22, Нг23 и т.д. Иногда может оказаться возможным получать приемлемые решения для всех подпроблем. В этом случае проектировщик должен выбрать вариант, который наилучшим образом удовлетворяет основной цели проектирования.
Предположим, например, что после выбора варианта аз и решения связанных с ним подпроблсм IFj/, W32, W33 обнаруживается, что решения для подпроблем W3211 следующего уровня не существует. Тогда необходимо отбросить вариант 0321 и попытаться найти решение для других проблем, связанных с вариантами АЗЗІ и АЗЗ Если, однако, окажется, что ни одна из подпроблем W3311 и W3321 не может быть решена, то необходимо вернуться к точке разветвления предыдущего, более высокого уровня (в данном случае к точке 0).
Методологические аспекты оптимального проектирования СУ сложными ТО с использованием эволюционной стратегии синтеза
Задача проектирования СУ сложными ТО связана с решением широкого круга взаимосвязанных проблем, таких как: классификация и распределение переменных, выбор рациональной иерархической структуры СУ, четкая формализация задач, решаемых на отдельных уровнях СУ, и соответствующих ограничений, рационального распределения функций человека и технических средств и других. Эффективное решение перечисленных задач следует ожидать лишь при использовании системных методов исследования [А18].
В процессе исследования системы проектирования СУ сложными ТО, как объекта автоматизации стремятся к наиболее полному и объективному представлению такого объекта -описанию его внутренней структуры, объясняющей причинно-следственные законы функционирования и позволяющей предсказать, а, значит, и управлять его поведением. Одним . из условий автоматизации является адекватное представление системы с управлением в виде сложной системы. Именно общие закономерности функционирования и свойства систем с управлением являются предметом изучения системного анализа. Принято считать, что системный анализ - это методология решения проблем, основанная на структуризации систем и количественном сравнении альтернатив.
Одним из центральных моментов при проектировании СУ сложными ТО на этапе научных исследований становится развитие системной методологии, заключающейся в изучении системы и ее поведения в целом как единого объекта, выполняющего определенную функцию в конкретных условиях.
В терминах теории множеств сущность системного подхода к проектированию заключается в том, что система проектирования (L) рассматривается, с одной стороны, как единая составная часть более общей системы (fi)), с которой она связана внешними связями (icQJ.c другой стороны, эта система включает целый ряд задач и их комплексов \Ll), тесно связанных между собой как потоками информации, так и общей целью функционирования: (L„Z2,...,Z„...,Z,„)e (2.1) Целостность системы проектирования определяется в этом случае тем, что её внутренние связи сильнее внешних, а также отличием характеристик информационных потоков, проходящих по этим связям (управляющие - для связи с внешней системой и проектные - для внутренних связей самой системы проектирования). Внешние связи системы проектирования являются рекурсивными, т.е. необратимыми, а её внутренние связи могут быть обратимыми, рекурсивными или циклическими.
При системном исследовании должны учитываться взаимодействие и взаимное влияние отдельных частей (подсистем) системы, существенные с точки зрения достижения системной заданной цели, воздействие окружающей среды и других систем, с которыми изучаемая система находится во взаимодействии или контакте. Системный подход - это учет всего, что влияет на выполнение системой своих задач и достижение ею своих целей. При этом сама цель функционирования системы, решаемые ею задачи должны быть осмыслены и сформулированы с учетом влияния изучаемой системы на другие системы и, в первую очередь, на систему более высокого иерархического уровня. Неправильно или узко понятые и нечетко сформулированные цель и задачи функционирования системы сводят на нет эффект системного исследования.
Системные исследования и подход к проектированию СУ ТО привлекали всегда большое внимание исследователей [77, 178, 79, 111, 173, 178, 181, 186, 192]. Системный анализ основывается на рациональном сочетании эвристических приемов, обобщающих опьп. интуицию и здравый смысл, с численными методами анализа и синтеза, ориентированными главным образом на применение современных ЭВМ.
Целесообразность применения системного подхода для анализа конкретной системы определяется её достаточной масштабностью (что позволяет ожидать значительный эффект по сравнению с исследованием системы по частям). Вместе с тем масштабы объекта системного исследования должны оставаться в рамках вычислительных возможностей ЭВМ [68]. Применение системного анализа при построении систем дает возможность выделить перечень и указать целесообразную последовательность выполнения взаимосвязанных задач, позволяющих не упустить из рассмотрения важные стороны и связи изучаемого объект автоматизации.
Структура объекта рассматривается с помощью моделей двух типов: иерархической модели и модели внутренней структуры.
В иерархической модели объект расчленяется на уровни согласно принципу подчинения низших уровней высшим. В общем случае любую систему можно подразделить на подсистемы определенного ранга (рисунок А.З). В качестве верхнего нулевого уровня целесообразно рассматривать суперсистему, т.е. систему, в которую исследуемый объект входит в качестве подсистемы первого ранга. Это позволяет уточнить состав подсистем суперсистемы, связанных с исследуемым объектом и входящих в его окружение.
При построении иерархической модели для конкретного объекта исследования декомпозиция отдельных подсистем по уровням может проводиться с различной глубиной: степень декомпозиции будет определяться спецификой решаемой задачи и имеющейся информацией об объекте.
В модели внутренней структуры отражаются взаимосвязи между элементами объекта в процессе функционирования, причем, как правило, элементы модели внутренней структуры полностью соответствуют нижним элементам иерархической модели (даже если элементы различных рангов). Для модели внутренней структуры характерна незначительная детализация имеющихся связей. В них обычно отражаются тип связи (материальная, информационная. кадровая и т.п.) и направление связи (откуда и куда).
Для описания вида взаимосвязей можно использовать различные обозначения. В модель внутренней структуры необходимо также включать элементы окружения, что позволяет конкретизировать источники и места приложения входов и выходов в канонической модели.
На основе решений о включении тех или иных элементов в состав модели объекта уточняются и конкретизируются назначение каждого элемента, функции, которые он выполняет в процессе работы всей системы, его входы и выходы - промежуточные параметры и переменные состояния объекта. Тем самым в модели внутренней структуры происходит как бы замещение элемента системы функциями, которые этот элемент выполняет, замещение связей между элементами связями между функциями, конкретизированные в виде переменных состояния. Затем требуется согласовать входы и выходы элементарных канонических моделей между собой и со входами и выходами канонической модели объекта в целом.
С этих позиций, как уже представлялось выше (в части 1.1 настоящей работы), весь процесс проектирования как процесс принятия решения можно разбить на три этапа [86]: ((внешнее проектирование», «формирование облика» технической системы и «внутреннее проектирование».
Ниже приводится системный анализ процесса проектирования СУ сложными технологическими системами (СУ ТО) в предположении 2-х уровневой их организации. Проектирование верхнего уровня СУ В соответствии с принятой терминологией первый этап (внешнее проектирование) предусматривает конкретизацию цели и задач проектирования СУ ТО. В общем случае этот этап предполагает выбор функции цели управления, под которой понимается мера эффективности ТО, усредненная подходящим образом по соответствующему интервалу времени и представляющая собой в общем виде функционал, зависящий от векторов входных переменных, управляемых входов и входных возмущений ТО. Выбор критерия оптимизации -самостоятельная и часто весьма сложная задача.
Таким образом, этап внешнего проектирования верхнего уровня завершается формированием наиболее приемлемого критерия управления ТО и системы накладываемых ограничений.
На этапе «формирование облика» прежде всего, проводится анализ выбранного критерия и системы накладываемых ограничений с точки зрения их сложности и возможности использования при управлении ТО. При этом предполагается наличие адекватных математических моделей статики и динамики элементов ТО.
Рассмотрение всех связанных с этим вопросов может привести к выводам о необходимости декомпозиции СУ ТО [4, 123, 192], позволяющей представить сё как ряд подсистем управления соответствующими технологическими подсистемами. При этом каждая подсистема управляет состоянием подконтрольной её части ТО. Функции координации взаимодействия подсистем при этом, осуществляются центральным алгоритмом. Естественным требованием к декомпозиции является обеспечение условий для анализа и синтеза подсистем, для проектирования, построения, внедрения, эксплуатации и совершенствования СУ ТО. Учет естественной декомпозиции, как правило, упрощает работу, подсказывает естественные пути декомпозиции системы. Однако, пользование этим правилом требует осторожности и критической оценки ситуации с учетом выбранных целей. Неверное использование приемов декомпозиции может привести к необоснованной разбивке на подсистемы и снижению эффективности СУ. Основные принципы и проблемы декомпозиции СУ ТО подробно рассмотрены в работе [24]. Показано, что эти методы не позволяют однозначно выявить структуру СУ ТО, однако их использование при исследовании позволяет выявить ряд потенциально приемлемых вариантов декомпозиции.
Декомпозиция СУ связана с решением ряда задач. Первой задачей декомпозиции является разделение системы на части с меньшим числом элементов и связей, т.е. с меньшим числом переменных величин. Разделение обычно производится из условий подчинения подсистем какой-либо классификации, например, по функции управления, по иерархии управления и др. Это правило обеспечивает унификацию подходов к подсистемам, но требует осторожности и критической оценки ситуации с учетом выбранных целей.
Разработка общей структуры и архитектуры программного обеспечения комплекса УК-01
Формализация задачи управления процессом проектирования СУ ТО схожа с постановкой задачи проектирования СУ ТО (см. ч. 1.2 настоящей работы).
Для выбора метода управления процессом проектирования СУ сложными ТО в рамках САПР в соответствии с выбранной концепцией проанализируем особенности задач, решаемых диспетчером проектов с использованием разрабатываемого УК.
Для достижения поставленных целен постоянно решаются следующие основные задачи: 1) расчет ориентировочного времени выполнения работ по отдельным этапам в рамках разрабатываемых проектов; 2) анализ шкал приоритетов для включаемых в разработку проектов; 3) формирование деревьев задач для рабочих групп при параллельном выполнении нескольких проектов с целью обеспечения непрерывности и полноты использования имеющихся ресурсов при накладываемых ограничениях по приоритетам для отдельных проектов; 4) оперативное слежение за намеченными сроками (графиками) выполнения отдельных этапов работ и проектов в целом; 5) формирование предложений по эффективному использованию ресурсов проектиро- вания, привлечение дополнительных ресурсов в случае необходимости и наличии возможности; 6) внесение изменений н корректировка фактических графиков выполнения отдельных этапов проектирования в соответствии с поступающей информацией об обнаруженных ошибках проектирования в процессе работы или невыполнении установленных сроков по отдельным группами разработчиков; 7) принятие оперативных решений о прерывании процесса проектирования по отдельным заданиям (проектам), переносе сроков реализации отдельных этапов и проектов в целом, перераспределении ресурсов проектирования, изменении сроков выполнения работ.
Это лишь основные задачи, которые постоянно решаются диспетчером проектов с использованием УК САПР СУ ТО. На практике диспетчер в ходе своей работы решает ряд дополнительных задач. При этом УК программно реализует анализ поступающих данных о ходе проектирования, выявляет типовые проблемы и генерирует рекомендации диспетчеру проектов для принятия окончательных решений. Принятые диспетчером решения реализуются также с использованием УК,
В целом в соответствии с принятой стратегией управления процессом проектирования работа диспетчера проектов в САПР СУ ТО представлялась в виде двух взаимосвязанных задач.
Задача 1. Проведение анализа всей поступающей в процессе проектирования информации о выполняемых работах и выявление проблем, основными из которых могут явиться: 1. Невыполнение планового графика работ. 2. Срыв конечных сроков завершения этапа (проекта). Исправление ситуации путем корректировки сроков исполнения этапов невозможно. Необходимо изменение конечных сроков - корректировка всего плана проектирования. 3. Выявлены ошибки в планировании очередей к рабочим группам. Например, два проекта стоят в очереди на выполнение N-ro этапа разработки АГ-го проекта. При этом есть возможность перенаправить один из них на выполнение другого этапа. 4. Выявлены ошибки в дереве заданий для одной из рабочих групп (например, порядок заданий не соответствует установленным приоритетам, сроков и других ограничений). Необходимость перестроения дерева заданий в соответствии с предъявляемыми требованиями. 5. Недостаточность ресурсов (вычислительных, числа разработчиков, исходных данных и др.). Проблема связывается с необходимостью структурной доработки или изменением исходного плана проектирования. 6. Выявлены ошибки проектирования на одном из этапов, требующие возврата к ранее выполненным этапам. 7. Проект, включенный в разработку, не поставлен в очередь (например, успешно пройдены N этапов проектирования, но переход к (N+JJ-му этапу, выполняемому другой профессиональной рабочей группой, не предусмотрен). 8. Выявлены непредвиденные простои разработчиков. 9. Выявлено завышенное потребление ресурсов (например, превышение запланированного числа разработчиков определенной группы, работающих над конкретным проектом при наличии нереализованной очереди по другим проектам для данной группы). 10. Выявлены ошибки в расчётных сроках завершения этапов (проектов); 11. Выявлены возможности улучшения качества диспетчирования.
Диспетчер проектов в данном случае является экспертом, который должен принять окончательное решение. Анализ и выявление проблем осуществляются диспетчером на основе результатов автоматизированной обработки информации (реализуемой в рамках УК), логики, профессиональных навыков, опыта, квалификации и интуиции.
Задача 2. Эта задача включает процедуры принятия решений (с учетом выдаваемых УК рекомендаций или без них), направленных на устранение возникающих проблем. Если решений несколько, то возникает задача выбора из нескольких альтернатив наилучшей из них. Принятие решений диспетчером может быть связанно с конкретными указаниями руководителей проектов. В большинстве же случаев в повседневной работе диспетчер сталкивается с часто повторяющимися видами проблем и решений, поэтому их эффективность является в большей мере резулЕ татом накопленного опыта, интуиции и творческих навыков. Исходной информацией для поиска и принятия решений в процессе проектирования являются данные, поступающие от руководителей проектов, руководителей рабочих групп, взаимодействующих с интерфейсами УК, в режиме реального времени.
Сложность управления проектами в рамках САПР СУ ТО заключается, прежде всего, в том, что она требует своего постоянного решения в условиях параллельной разработки большого числа проектов и с возрастанием числа проектов ее решение становится сложнее, а объем анализируемых данных увеличивается. Особенностью выбранной концепции организации процесса проектирования является условие реализации непрерывной работы над проектами в САПР СУ ТО, что может быть достигнуто только за счет эффективного оперативного управления ходом выполнения работ.
Генерация рекомендаций (альтернативных вариантов решений) по диспетчированию и построению дерева заданий для рабочих групп происходит на основе анализа множества факторов, часть из которых может быть ранжирована. Под заданиями здесь следует понимать этапы проектирования, выполняемые рабочими группами и отображаемые в дереве задач для каждой группы. Например, при разработке одновременно нескольких проектов в САПР СУ ТО может встать задача по выполнению этапа «Разработка обобщенной структурной схемы моделируемой системы», которую нужно выполнить сразу для нескольких проектов. Тогда,, проанализировав факторы ранжирования, УК перестроит дерево задач для группы, отвечающей . за выполнение данного этапа.
В качестве неранжирусмых факторов целесообразно использовать следующие данные: 1. Наличие исходных данных (0 - отсутствие, 1 - наличие). 2. Занятость отдельных специализированных профессионально-ориентированных групп (О - отсутствие, 1 - наличие). Этот фактор определяется на основе текущего анализа: а) матрицы взаимосвязи задач и этапов их решения по конечным результатам, определяющая последовательность выполнения отдельных этапов; б) этапа (этапов) решаемой (решаемых) задачи (задач) в отдельных профессионально-ориентированных группах; в) вида решаемых в текущий момент времени задач. 3. Наличие достаточных вычислительных ресурсов (0 - отсутствие, 1 - наличие).
Для формирования рекомендаций по управлению проектами, выдаваемых УК, используются следующие ранжируемые факторы: приоритет проекта, над которым ведется работа, - задается при добавлении нового проекта в САПР - может быть изменен в ходе работы над проектом; сроки планируемого начала и конца работы над этапом (проектом); трудоемкость выполнения этапа (проекта в целом) - задается при добавлении нового проекта в САПР и .. может быть изменена в ходе работы над проектом; показатель эффективности использования принятых ранее решений по возникшей проблеме (отношение количества принятых к. исполнению решений к общему числу сгенерированных УК решений по данной проблеме). Число ранжируемых факторов может быть изменено в зависимости от класса решаемых в рамках САПР СУ ТО задач. Ранжируемым факторам присваиваются соответствующие весовые коэффициенты, указывающие на их значимость. Принятый диапазон значений весов от 0,001 до 0,999. Задание весов происходит в настройках УК. Базовые установки весов производят при начальной настройке УК.
При анализе факторов в процессе генерации альтернативных вариантов решений при управлении процессом проектирования устанавливается жесткая очередность их рассмотрения. Вначале анализируются неранжируемые факторы, являющиеся группой жестких ограничений, Значение хотя бы одного их этих факторов, равное «0» (нулю), означает невозможность выполнения проектных работ на данный момент времени. В таком случае анализ ранжируемых факторов не имеет смысла. На основе оценки ранжируемых факторов УК в соответствии с реализованными в нем алгоритмами строит деревья заданий для различных групп разработчиков и представляет нх диспетчеру для принятия окончательных решений.
Неоднозначной величиной является оценка трудоемкости этапов при планировании процесса проектирования. Такая оценка осуществляется еще на стадии включения нового проекта в САПР. Эта задача обычно решается в рабочем порядке руководителями проектов и групп разработчиков с участием диспетчера проектов. Оценка проводится на основе укрупненного анализа технологических схем и накопленных данных о среднестатистических временных характеристиках выполнения отдельных работ в процессе проектирования СУ ТО. Получаемые оценки являются исходными данными для расчета плановых сроков выполнения отдельных этапов проектирования, которые могут корректироваться по результатам работы групп или других факторов, учитываемых в процессе функционирования САПР СУ ТО.
Внедрения результатов исследования в промышленности
Использованные компоненты (кроме OfficeExporter) являются бесплатными и распространяются свободно. OfficeExpotrter в базовой (бесплатной) поставке имеет ряд ограничений на форматы и максимальные размеры экспортированных файлов, что не является критичным на начальных этапах использования УК или для демонстрации его работы.
Отметим, что возможно использование серверов БД, находящихся в ЛВС предприятия, т.е. сервер БД не обязательно размещается на рабочем ПК диспетчера проектов. В случае виртуализации САПР в вычислительном облаке доработка программного кода УК-01 САПР СУ ТО не потребуется - в программном комплексе реализованы все необходимые для этого функции.
Дополнительное программное обеспечение. УК-01 САПР СУ ТО работает под управлением операционной системы MSWindowsXP/Vista/Seven. Приложение является 32-битным.
Для просмотра сформированных в «Менеджер отчетов» документов необходимо наличие прикладных программ MSOffice (Word, Excel) и AdobePDFReader или их аналогов.
Обязательно наличие установленной и поддерживаемой УК-01 СУБД. Предложена к использованию СУБД MSSQL. Перед эксплуатацией УК-01 запускается процедура диагностики БД н устранения найденных ошибок. Рекомендуется использование на рабочих станциях, где используется УК-01 или любой другой компонент САПР СУ ТО средства защиты от вирусов и взлома системы. Прочего программного обеспечения для работы УК-01 САПР СУ ТО не требуется.
Не планируется отдельная разработка клиентского приложения для различных видов пользователей. Начало работы с УК начинается с запуска подсистемы «Авторизация». Работа других подсистем без запуска этой подсистемы невозможна. После авторизации пользователь в зависимости от прав доступа может через главное окно комплекса запустить одну из трех . подсистем: «Днспетчирование», «Рабочие группы», «Администрирование».
Что касается логики представления данных (пользовательский интерфейс), то здесь она может быть выделена в отдельный уровень, прежде всего для того, чтобы обеспечить независимость ее от состава и структуры представляемых данных, что крайне необходимо для обеспечения возможности использования разработанной архитектуры во всех функциональных подсистемах комплекса с самым различным составом элементов их БД.
Что касается обработки данных, то здесь логика может быть различной. Собственно она и является функциональным программным обеспечением подсистем комплекса, реализующим разработанные машинно-ориентированные алгоритмы обработки данных.
И, наконец, управление подсистемой предназначено для координации ее работы путем реализации связующих функций между элементами программной логики самой подсистемы.
Основными задачами управления являются инициализация и запуск функций соответствующего уровня программной логики и контроль за их исполнением в процессе решения всего спектра возложенных на подсистему задач.
Естественно предположить, что обеспечение независимости отдельных уровней программной логики друг от друга позволяет повысить эффективность разработки программного обеспечения за счет снижения количества изменений одного уровня при изменении другого. Так, например, изменение метода доступа к данным совершенно не изменит их представление пользователю. Все это обеспечит инвариантность эффективное ги функционирования разрабатываемой системы к изменениям в составе используемых технологий. А изменение логики проведения расчета не должно вызвать изменений в интерфейсе и методах доступа к данным, что исключит необходимость их повторной отладки.
УК-01 САПР СУ ТО является приложением, которое должно обеспечить одновременную работу большого числа пользователей [110]. Пользователи, в зависимости от своей группы, имеют доступ к подсистемам УК-01 и могут выполнять различные действия по редактированию данных в БД. Организация многопользовательского режима является важной задачей, от качества решения которой зависит удобство и эффективность использования УК-01. Следует отмстить, что УК-01 планируется эксплуатироваться в рамках одной или нескольких организаций, а пользователи могут находиться в различных узлах локальной вычислительной сети либо объединены посредством Интернета.
Взаимодействие пользователей с УК может осуществляться по клиент-серверной технологии, получившей широкое распространение в корпоративном секторе [87, 93].
Ввиду постоянного увеличения требований со стороны заказчиков, необходимости решения все новых проблем, увеличения объемов обрабатываемых данных и количества пользователей сложилось несколько подходов к разработке клиент-серверных приложений для корпоративного сектора различных по взаимодействию между клиентом и сервером [95].
Сервер характеризуется видом оказываемой услуги; центральное место в корпоративных системах занимают серверы баз данных и серверы приложений. Традиционным стал взгляд на технологию клиент-сервер как на систему трех взаимодействующих компонентов [95]: представление (пли front-end) - реализует функции ввода и отображения данных; приложение (business-logic) - объединяет чисто прикладные функции, характерные для предметной области; СУБД (resourcemanager) - управляет доступом к данным, контролирует целостность БД и т.д.
Эти компоненты могут быть по-разному распределены в сети и реализованы различными средствами (моделями): удаленные данные; сервер базы данных; сервер приложений.
Первая модель самая простая и иногда используется для реализации современных клиент-серверных приложений с небольшими объемами обрабатываемых данных и малым числом пользователей. Главное ее достоинство - обилие инструментальных средств разработки приложений для Windows, работающих с SQL-серверами через стандартный интерфейс ODBC. Что касается недостатков, то большая часть критических замечаний относится именно к этой модели: плохой отклик из-за чрезмерной загрузки сети, невозможность удовлетворительного администрирования приложений. Причина этого неприятного явления в том, что различные по своей природе функции смешиваются в одной программе. При коллективной работе над проектом, когда каждый разработчик автоматизирует «свои» типы рабочих мест, становится в высшей степени сложно контролировать взаимную непротиворечивость алгоритмов обработки данных, встраиваемых в многочисленные компоненты front-end. Аналогичные трудности возникают и при необходимости внесения сквозных изменений в проект.
В основе второй модели лежит механизм хранимых процедур — средство программирования ядра СУБД. Сегодня этот механизм реализован во всех SQL-серверах, представленных на рынке. Прикладной компонент оформляется как набор хранимых процедур языка SQL и переносится на компьютер - сервер БД. Преимущества такого подхода очевидны: снижается трафик сети, появляется возможность централизованного администрирования функций обработки данных, а также их разделения несколькими приложениями. Недостатки же связаны с тем, что процедурное расширение SQL не является полноценным языком программирования. Отсутствие средств отладки и тестирования хранимых процедур в большинстве СУБД может превратить их в потенциально опасный механизм. Поэтому на практике в виде хранимых процедур обычно реализуются лишь простейшие функции, тесно связанные с доступом к данным, в то время как большая часть обработки данных по-прежнему осуществляется на компьютере-клиенте. Такая «смешанная» модель сегодня, пожалуй, применяется наиболее широко, однако для разработки систем масштаба предприятия она оказывается малопригодной даже в случае удовлетворительного решения проблемы комплексной отладки обеих частей распределенного приложения. Дело в том, что ядро типичной СУБД, ориентированной на SQL, не совсем подходит для организации баланса загрузки серверов, миграции процедур между серверами, выполнения приоритетных запросов и т.д.
