CC BY
61
В результате можно сделать следующие выводы.
Расчет первым способом возможен только тогда, когда переходный процесс на самом деле является затухающим. Второй способ требует циклических операций и при многократных вычислениях потребует большего времени. Третий способ имеет минимальный программный код, но требует дополнительных блоков simulink.
Литература
1. Мерзлякова О.В., Бильфельд Н.В. Получение массива в рабочую среду MATLAB и построение переходного процесса // Молодежная наука в развитии регионов. 2011. С. 14-20.
2. Ануфриев И. Самоучитель MatLab 5.3/6.Х. СПб: БХВ-Петербург, 2002. 512 с.
3. Черных И.В. Моделирование электротехнических устройств в MATLAB, SymPowerSystem и Simulink. СПб: Питер, 2008. 288 с.
4. Затонский А.В. Программная оптимизация настроек систем автоматического регулирования // Новый университет, 2011. № 1. С. 28-33.
References
1. Merzlyakova O.V., Bilfeld N.V., Youth Science in the development of the regions, 2011, pp. 14-20.
2. Anufriev I.E., Tutorial MatLab 5.3/6.x, St. Petersburg, BHV-Petersburg Publ., 2002, 512 p.
3. Chernykh I.V., Modeling of electrical devices in MATLAB, SymPowerSystem and Simulink, St. Petersburg, Peter Publ., 2008, 288 p.
4. Zatonsky A.V., New University, 2011, no. 1, pp. 28-33.
УДК 658.512.22
ПРЕДСТАВЛЕНИЕ ПРОЦЕССОВ ПРОЕКТИРОВАНИЯ
В ФУНКЦИОНАЛЬНО АДАПТИРУЕМОЙ ФОРМЕ ДЛЯ ХРАНЕНИЯ КЛАССОВ ПРОЕКТНЫХ РЕШЕНИЙ
(Исследование выполнено при поддержке Министерства образования и науки РФ, соглашение № 14.B37.21.1142)
И.В. Горбачев, к.т.н.; А.Ф. Похилько, к.т.н., доцент (Ульяновский государственный технический университет, ул. Северный Венец, 32, г. Ульяновск, 432027, Россия, [email protected])
Возможности взаимодействия при распределенном и параллельном проектировании во многом определяются способом представления проектных решений в системах автоматизированного проектирования. В настоящее время обмен решениями осуществляется средствами формата стандарта ISO 10303 STEP, разработанного в рамках CALS-технологии, который не позволяет модифицировать решения. В данной статье рассматриваются возможности выделения из проектной деятельности структур проектных решений, построения моделей классов объектов проектирования, а также хранения, отображения и дальнейшего использования информации в контексте технологии функционально адаптированного представления (ФАП). Развиваемая авторами концепция ФАП позволяет иным, в отличие от известных, способом подойти к обмену проектными решениями, когда главным является фиксация процедуры получения решения (последовательности операций), на основе которой средствами инструментальной среды генерируется по сути мини-САПР с функциональностью, определяемой набором операций, необходимых для создания проектируемого объекта. При этом сохраняются логика проектного процесса и возможность его модификации (модификации проектного решения) в пределах выделенного класса проектных операций.
Ключевые слова: интегрированная среда, проектная деятельность, проектные решения, автоматизация, САПР.
DESIGNING PROCESS REPRESENTATION IN FUNCTIONALLY ADAPTED FORM FOR STORE OF THE PROJECT SOLUTIONS CLASS
Gorbachev I.V., Ph.D., Associate Professor; Pokhilko A.F., Ph.D., Associate Professor (UlyanovskState Technical University, 32, Severny Venets St., Ulyanovsk, 432027, Russia, [email protected]) Abstract. The interoperability of distributed and concurrent designing is defined by the representation of CAD systems project solutions. Nowadays solution exchange is performed through standard ISO 10303 STEP format, created in the frames of CALS technology and doesn't allow modifying solutions. This article describes project solutions extraction capability from design activity, designing object class models formation, as well as store, map and further use of information in the context of the functionally adapted representation. The functionally adapted representation concept allows solution exchange by the other method. In this case, the main thing is the fixation of solution construction procedure (consists of operation chain) in the procedure chain. On the base of procedure chain mini CAD is generated by author's instrumental environment. Mini CAD is small software application for designing. Mini CAD functionality is determined by required operation set for
designed object creation. In this case, the logic and the modify ability of project process is saved inside of selected project operation class.
Keywords: IDE, project activity, project solutions, automation, CAD.
Современная стратегия развития производственных систем в значительной мере определяется инфокоммуникационными технологиями [1], обеспечивающими создание так называемых виртуальных предприятий, то есть производственных структур, взаимодействие между подразделениями которых осуществляется на базе современных средств телекоммуникаций с использованием стандартов информационного взаимодействия (CALS-стандартами) между информационными системами (проектирование, производство, управление процессами) на всех стадиях жизненного цикла изделий и услуг.
Существующие опыт и практика развития соответствующих инфокоммуникационных технологий выдвигают на передний план необходимость исследования и развития методов представления проектной информации (проектных решений), обеспечивающих не столько обмен между различными информационными системами или сервисами, сколько сохранение, модификацию и обобщение информационных представлений проектных решений [2]. В [3] изложены теоретические предпосылки (математическая модель) описания и модификации проектных решений на основе формализации процесса их получения в форме многоуровневой системы протоколов создания проектных решений средствами современных САПР. Рассматривая структуру информационного представления проектных решений, можно констатировать, что описание проектного решения создает основу для его обобщения в форме описания класса проектных решений как более высокоуровневой абстракции информационного представления [4].
Дальнейшее развитие технологий требует поддержки не только обмена результатами деятельности внутри виртуальных предприятий, но и возможности быстрой корректировки решений (например, при изменении требований заказчика). В настоящее время полноценно это может достигаться только за счет внедрения у всех участников виртуального предприятия программных средств от одного и того же производителя. Внедрение же всевозможных конверторов форматов и дополнительных средств обработки результатов проектирования приводит к потере логических связей внутри модели проектируемого объекта, а следовательно, и к нарушению его целостности.
Невозможность полноценного обмена между различными системами связана с частичным или полным отсутствием интероперабельности. Поэтому достижение интероперабельности остается серьезной проблемой, создающей трудности для полноценного обмена результатами проектной деятельности между различными САПР. Предла-
гаемые подходы к решению данной проблемы не могут быть реализованы по нескольким причинам: все автоматизированные системы твердотельного проектирования никогда не будут иметь абсолютно одинаковый набор конструктивных элементов, так как потеряют свои конкурентные преимущества так же, как невозможно в рыночных отношениях заставить всех пользоваться только одной и той же САПР [5].
В данной работе рассматривается структура информационного представления проектных решений в функционально адаптируемой форме [6], позволяющей реализовать в виде приложений обобщение проектных решений в форме классов информационных объектов.
Постановка задачи
Исходя из вышесказанного, задачу можно сформулировать следующим образом: необходимо создать инструментальную среду, которая обеспечивала бы выполнение следующих требований:
- возможность интеграции разнородных приложений удобным для пользователя образом;
- развязка разнородной информации для обработки в специализированных приложениях;
- работа с содержимым проектного решения, его идейным наполнением;
- контекстность предоставляемой пользователю информации;
- отвязка от конкретных форматов данных и их преобразований;
- формирование независимых приложений, обеспечивающих обработку проектного решения в рамках функциональности, использованной для его построения.
Для возможности создания инструментальной среды необходимо разделить информационные потоки между модулями системы, чтобы обеспечить работу специализированных приложений только с характерной для них информацией, а также разработать и реализовать БД и модуль управления, которые обеспечивали бы следующее:
- хранение проектных решений;
- динамическое наполнение множества проектных решений;
- хранение сопутствующей информации (описаний, вычислений и пр.);
- управление внешними функциональными модулями-компонентами среды, обмен данными между модулями и их сохранение;
- выдачу и отображение в удобном виде хранящейся информации;
- удобное управление проектами со стороны пользователя.
Для формирования независимых приложений каждый модуль инструментальной среды должен быть представлен также в виде текстов исходных кодов, организованных так, чтобы можно было выделить только требуемый функционал и скомпилировать на его основе «урезанную» версию модуля. Соответственно, в состав инструментальной среды должен входить компилятор.
Модель и содержание решения
Как показывает практика, создание системы, удовлетворяющей всем возникающим требованиям (используя единую информационную среду, обеспечивающую однородность данных и автоматизацию обмена данными на протяжении всего процесса проектирования, причем не только проектирования, но и всего жизненного цикла изделия), могут позволить себе лишь очень крупные концерны. Отсутствие на данный момент возможности создать такую систему приводит к мысли о разработке инструмента, позволяющего объединять существующие в настоящее время и используемые в процессе проектирования и всего жизненного цикла изделия приложения. Упрощенная схема такой системы приведена на рисунке 1.
Появление концепции технологии функционально адаптивного представления обусловило необходимость создания системы, оперирующей с моделью процесса проектирования на тех же принципах, но обладающей возможностью выделения процесса проектирования объекта (или класса объектов) в независимое приложение. Для этого в общую схему инструментальной среды были внесены следующие изменения. Каждое приложение, с которым может работать пользователь, представляется как функциональная подсистема. Каждая подсистема предоставляет свой интерфейс взаимодействия для работы через управляющий модуль в общий интерфейс пользователя,
сама фиксирует и сохраняет протокол действий пользователя. Управляющий модуль (подсистема управления проектами) обеспечивает средства для организации сохраненной последовательности действий пользователя в виде проектных процедур, предоставляет пользователю возможность через интерфейс подсистемы генерации функционально адаптированных (ФА) САПР выбрать необходимые цепочки действий для генерации ФА САПР. Включенная в состав среды подсистема генерации ФА САПР отвечает за процесс выборки требуемого функционала и компиляции исполняемого файла ФА САПР. Упрощенная схема разработанной системы приведена на рисунке 2.
Перейдем к модели представления процесса получения проектных решений. Проводившиеся ранее исследования и работы показывают эффективность и доступность для пользователя и программиста метода представления процесса проектирования в виде И-ИЛИ-графа. Вершинами графа являются элементы технической системы (ТС) и их признаки, а дуги показывают иерархическую соподчиненность между элементами и их признаками и принадлежность признаков элементам. В вершинах множества И располагаются элементы, выполняющие различные функции, а также признаки элементов, относящихся к разным группам признаков. Вершины ИЛИ объединяют альтернативные элементы, выполняющие одинаковые или очень близкие функции, и признаки, характеризующие индивидуальные особенности каждой ТС.
Множество путей достижения технического решения (прохождение по вершинам И-ИЛИ-графа) может быть представлено в виде логической записи (предиката), где при выполнении всех условий принимается значение «истина», а в противном случае - «ложь». Форма записи следующая: Р(А&(£иСиД)&^Н0; 1], где А, ^ - элементы, выполняющие различные функции; В, С, Б -альтернативные элементы, выполняющие близкие функции. Решение системы уравнений, представленных в предикатной форме, и есть удовлетворяющее ТЗ техническое решение.
Недостатки существующих реализаций этого метода: неполнота набора вариантов ТС, невозможность внесения изменений и добавления новых решений.
Другим подходом может стать динамическое наполнение множества проектных решений, то есть построение и наращивание графа во время самого процесса проектирования, что сразу же устраняет вышеописанные недостатки, но накладывает более жесткие требования к обработке и хранению данных. В ходе анализа задачи были выделены несколько сущностей, реализация и использование которых позволили бы динамически строить граф проекта, использовать полученные решения ТС, удобно отображать сопутствующую проекту служебную и справочную информацию.
Рис. 2
• Проект (Пр) - наибольшая абстракция, которая включает в себя дерево решений и всю сопутствующую информацию.
• Проектная процедура (1111) - некое действие, выполняемое пользователем и выделяемое им в отдельную смысловую единицу. Она разделяется на три элемента:
- процедура тип1 (П1) - процедура, являющаяся выполнением некоторых действий, которые лишь в совокупности обладают смыслом для пользователя; то есть применительно к системе 3D-проектирования это набор строчек макроса, выполнение которых внешним модулем или другой программой приводит к некоему результату, имеющему смысл для пользователя (скажем, от-рисовка окружности с последующей вытяжкой (для SolidWorks));
- процедура «назначения» (тип2) (П2) - процедура, являющаяся назначением параметру приложения, «участвующего» в системе, значения (например, назначение размеру некоторого числа);
- условие (У) - процедура проверки истинности некоторого условия, задаваемого в ходе работы с проектом; обеспечивает «ветвление дерева проекта», накладывается на параметр (см. термин ниже), может быть нескольких типов (существование, равенство, различные неравенства и принадлежность диапазону).
• Параметр (П) - некая абстракция, интерпретируемая в зависимости от контекста. По смыслу близка к переменной. В реализуемой системе может содержать в себе постоянную величи-
ну, расчет, SQL-запрос, интерактивный запрос. В перспективе может хранить любую информацию, интерпретация которой будет зависеть от контекста, в котором применяется параметр.
Основу модели составляют множества:
- проектов, Пр{Прг<кеу, Name, Desc>}, где key - уникальное число-идентификатор проекта (уникальное числовое значение записи в БД (далее будет опускаться)); Name - имя проекта (краткое смысловое содержание); Desc - описание содержания проекта;
- проектных процедур, ПП{ПШ <ProjID, Type, Name, Desc, NOP1, NOP2>}, где Type - тип элемента множества (1 - П1, 2 - П2, 3 - У); Name - имя элемента, отражающее смысловое наполнение; Desc - подробное описание; NOP1 - уникальное число, определяющее элемент множества, на который происходит переход после выполнения условия У; NOP2 - уникальное число, определяющее элемент множества, на который происходит переход после невыполнения данного условия;
- процедур тип1, ni{nii<OpID, Content>}, где OpID - уникальное число, определяющее элемент множества ПП, с которым однозначно связан данный элемент; Content - содержимое элемента (текст макроса, скрипта и т.п.);
- процедур тип2, П2{П2г<ОрГО, ParamID>}, где OpID - уникальное число, определяющее элемент множества ПП, с которым однозначно связан данный элемент; ParamID - уникальное число, определяющее элемент множества П, числовое зна-
чение которого будет использовано при выполнении данного элемента множества П2;
- условий, y{yi<OpID, ParamID, ParamIDI, ParamID2, Condition>}, где OpID - уникальное число, определяющее элемент множества ПП, с которым однозначно связан данный элемент; ParamID - уникальное число, определяющее элемент множества П, числовое значение, на которое будет накладываться условие; ParamIDI - уникальное число, определяющее элемент множества П, числовое значение которого будет использовано при выполнении данного элемента множества У (левая граница диапазона); ParamID2 - уникальное число, определяющее элемент множества П, числовое значение которого будет использовано при выполнении данного элемента множества У (правая граница диапазона); Condition - собственно условие, налагаемое на элемент множества П;
- параметров, n{ni<ProjID, Name, Type, Content, Desc, Value>}, где ProjID - уникальное число, определяющее принадлежность данного элемента к проекту; Name - имя элемента; Type -тип (число), согласно которому интерпретируется содержимое элемента; Content - содержимое элемента; Desc - описание элемента; Value - числовое значение, возможно, получаемое при интерпретации содержимого элемента.
Процесс проектирования можно представить в виде совокупности элементов множества ПП. Каждый элемент множества ПП представляет собой отдельную реализованную подзадачу проектирования. Таким образом, существует возможность описать проект Пр, используя реализованные проектные решения: Пр=т1&т1&У1((Ш,&П2/& ...) or (Ук(...))), где i, /, k - индексы элементов множеств, адекватные проектным ситуациям.
Создание нового и пополнение проектного решения начинается с выделения некоторой области задач, в которую будет вписываться проект (создание или выбор элемента множества Пр). Далее следуют пополнение и (или) изменение элементов всех остальных множеств в контексте данного проекта, что позволяет автоматически поддерживать связь между элементами множеств. Посредством этих связей в дальнейшем можно восстановить дерево проекта.
Воспроизведение проектного решения заключается в выборе элемента Прi и дальнейшем прохождении по ветвям дерева с обработкой элементов множества ПП.
Так как каждая проектная процедура состоит из множества проектных операций (элементарных действий, доступных пользователю при работе с системой), их можно однозначно связать с классами исходного кода приложения, в которых они реализованы. Специальная организация и выделение необходимых классов дают возможность сгенерировать урезанную версию приложения, обладающего набором функциональности, доста-
точным для построения и редактирования такого проектного решения.
Для реализации рассмотренного выше подхода была смакетирована система, состоящая из трех компонентов: центрального модуля (он же модуль работы с БД), графического редактора на основе геометрического ядра Open CASCADE и интерфейсного модуля, поддерживающего работу с математическим процессором MathCAD.
Апробация
Результатом реализации стали макет программного комплекса из трех компонентов и его апробация на множестве типовых задач проектирования машиностроительных деталей и узлов. В исходном виде процесс проектирования описывается как типовая методика, включающая описание как задачи в текстовом виде, так и графических эскизов и последовательности математического расчета. Подтверждены принципиальная работоспособность системы, ее возможность сохранять накопленные проектные решения. Функциональные возможности системы соответствуют исходным предположениям.
Одной из задач, рассмотренных во время апробации, была задача проектирования резцов. Выбор различных ветвей общего дерева решений позволяет на выходе получить различные приложения (рис. 3) - «ФА САПР Призматический резец», то есть инструмент проектирования объектов класса призматический резец, либо «ФА САПР Круглый резец» для проектирования объектов класса круглый резец. Если же выбрать ветви дерева решений, соответствующие обоим резцам, то будет сгенерирована ФА САПР для построения резцов обоих типов, то есть класс объектов, которые можно будет проектировать с помощью такого инструмента, еще более расширится.
К направлениям для дальнейшей работы можно отнести усовершенствование механизма проведения расчетов и наглядное отображение дерева проекта.
Проведенный программный эксперимент, несмотря на некоторые недоработки в ИИС в целом
в связи с согласованием работы отдельных компонентов, показал возможность создания подобных интегрированных сред и успешного хранения не только сопровождающей проектной информации, но и информации, касающейся «идейного» наполнения проекта, эффективно решать задачи построения модели процесса проектирования, моделирования классов объектов проектирования.
Перспективы развития:
- улучшение механизма расчетов в математическом процессоре;
- добавление возможностей параметризации не только размеров, но других величин (в том числе нечисленных);
- обеспечение работы не только с деталями, но и со сборками, то есть включение других проектов как подветвей;
- оптимизация взаимодействия с пользователем;
- расширение набора служебных модулей для взаимодействия с другими приложениями;
- переход к новой модели хранения проектных решений в виде потокового графа.
Дальнейшее развитие технологии и разработка полноценной математической системы на основе математического ядра, построенного по принципу геометрического ядра Open CASCADE, откроет возможность реализации полнофункциональной интерактивной системы построения функционально адаптированных САПР. Такая система не только обеспечит разработчиков эффективным средством обмена проектными решениями, но и откроет возможности для быстрой автоматизации рабочих мест специализированными инструментами проектирования на основе функционально адаптированных САПР.
Литература
1. Судов Е.В. Интегрированная информационная поддержка жизненного цикла машиностроительной продукции. Принципы. Технологии. Методы. Модели. М.: МВМ, 2003. 264 с.
2. Sobolewski M. Foreword Next Generation Concurrent Engineering: Smart and Concurrent Integration of Product Data, Services, and Control Strategies, 2005, ISPE, 620 p.
3. Похилько А.Ф. Четырехуровневая иерархия процессов обработки процедурных знаний в интегрированной информационной среде автоматизации проектной деятельности // AIS-IT'09: тр. конгр. М.: Физматлит, 2009. Т. 2. С. 52-53.
4. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений. М.: Вильямс, 2008. 720 с.
5. Hamilton P. Азбука технологий моделирования в MCAD-системах. Ч. III. Как технологии MCAD влияют на процесс разработки изделия // CAD/CAM/CAE Observer. 2008. № 2 (38). C. 34-36.
6. Похилько А.Ф. Инструментарий представления процессов проектной деятельности в функционально адаптируемой форме // AIS-IT'010: тр. конгр. М.: Физматлит, 2010. Т. 2. С. 104-106.
References
1. Sudov E.V., Integrirovannaya informatsionnaya pod-derzhka zhiznennogo tsikla mashinostroitelnoy produktsii. Printsipy. Tekhnologii. Metody. Modeli [Integrated information life cycle support machinery. Principles. Technology. Methods. Model.], Moscow, MVM, 2003, 264 p.
2. Sobolewsky M., Foreword Next Generation Concurrent Engineering: Smart and Concurrent Integration of Product Data, Services, and Control Strategies, 2005, ISPE, 620 p.
3. Pokhilko A.F., Trudy kongr. AIS-IT'09 [Proc. of the Congr. AIS-IT'09], Moscow, Fizmatlit, 2009, Vol. 2, pp. 52-53.
4. Booch G., Object-oriented analysis and design with applications, Moscow, Williams, 2008, 720 p.
5. Hamilton P., CAD/CAM/CAE Observer, 2008, no. 2 (38), pp. 34-36.
6. Pokhilko A.F., Trudy kongr. AIS-IT'010 [Proc. of the Congr. «AIS-IT'10»], Moscow, Fizmatlit, 2009, Vol. 2, pp. 104-106.
УДК 004.91
МЕТОД ИНФОРМАЦИОННОЙ ПОДДЕРЖКИ ВЫПОЛНЕНИЯ СТРУКТУРНО-СЛОЖНЬЖ ПРОЕКТОВ
Р.В. Допира, д.т.н.., зав. отделением (НИИ «Центрпрограммсистем», пр. 50лет Октября, 3а, г. Тверь, 170024, Россия, [email protected]); Р.Ю. Кордюков, к.т.н.., начальник отдела (Департамент Минобороны РФ по обеспечению гособоронзаказа, Фрунзенская наб., 22/2, г. Москва, 119146, Россия); А.В. Лобузько, генеральный директор (Компания «Росспецтехмонтаж», ул. 8 Марта, 10, стр. 1, г. Москва, 127083, Россия);
А.А. Беглецов, ст. инженер (Военное представительство МО РФ, ул. 1-я Бухвостова, 12/11, г. Москва, 107076, Россия);
Талалаев А.Б., д.т.н.., генеральный директор (Компания «Радиотехнические и информационные системы воздушно-космической обороны», ул. З. Коноплянниковой, 89, корп. 1, г. Тверь, 1 70026, Россия)
Сформулирована и формализована задача разработки метода информационной поддержки выполнения структурно-сложных, разнесенных во времени и пространстве проектов. Под проектом понимается совокупность опера-
