Структура формального представления процесса проектирования в функционально адаптированной САПР

Автор: Горбачев И.В., Похилько А.Ф.

Журнал: Инфокоммуникационные технологии @ikt-psuti

Рубрика: Новые информационные технологии

Статья в выпуске: 1 т.8, 2010 года.

Бесплатный доступ

В статье рассматривается структура функционально адаптированной САПР и принципы работы с ней. Описывается структура формального описания объектов информационного пространства функционально адаптированной САПР и принципы формирования условий

Короткий адрес: https://sciup.org/140191378

IDR: 140191378

Текст обзорной статьи Структура формального представления процесса проектирования в функционально адаптированной САПР

Проблема обмена решениями между различными САПР, на сегодняшний день, остается не решенной. Разработанный формат ISO 10303 STEP позволяет передать геометрическую модель объекта из одной системы в другую, но передается только геометрия модели. Логику (дерево) построения модели передать из одной геометрической среды в другую без искажений практически невозможно. Внесение в существующие модели изменений является необходимым элементом инфокоммуникационного взаимодействия в проектной деятельности с использованием современных информационных технологий, так как по существу означает невозможность использования «опыта со стороны» [1].

Сложность проблемы достижения интероперабельности в данном контексте является принципиальной. CAD-системы от различных производителей проектирования никогда не будут иметь в точности одинаковый набор операций, так как потеряют свои конкурентные преимущества; так же как невозможно в рыночных условиях заставить всех пользоваться только одной и той же САПР [2].

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

За счет включения в ФА САПР конвертора STEP, модель можно передать в любую другую систему. Если возникает необходимость внести в модель изменения, то ФА САПР обладает достаточным функционалом для этого.

Структура функционально адаптированной САПР

В состав ФА САПР входят три модуля:

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

  • -    библиотеки графического ядра: набор перекомпилированных библиотек, из состава которых удалена избыточная функциональность. Для построения ФА САПР требуется ядро геометрического моделирования. Для проведения программного эксперимента используется геометрическое ядро Open CASCADE. Исследо-

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

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

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

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

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

Структура формальной логики процесса проектной операции

Описание процессов возможно с использованием ICOM модели. В нашем случае, описание процесса построения модели, так же возможно с применением методологии ICOM.

Процесс проектирования, описанный в терминах ICOM представлен на рис. 1. На вход работы поступает техническое задание (ТЗ) на проектирование технического объекта (ТО), которое описывается как множество входных параметров вида

ТЗ = { ах; а2 ... лх }.

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

Рис. 1. ICOM модель проекта

Модель ТО – результат проектирования, представленный в виде конкретного решения (конкретной модели), сохраненной в виде обменного файла формата STEP. Так как каждая ФА САПР представлена в виде конкретного проекта, то М на рис. 1 – это механизм, который представляет собой упорядоченную последовательность проектных операций ПрО , формирующуюся в процессе проектирования, то есть

ПрО = {ПрО[, ПрО^ ... ПрО^} – множество всех проектных операций.

Рис.2. Декомпозиция модели проекта

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

Р(ах2,...,а^ вида

.

Данное решение будет верным, так как решение образуется путем фиксации шагов проектирования верного решения.

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

Рис. 3. Структура проектной операции

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

Если механизм исполняемых процедур описывается некой функцией и,при выполнении проектной операции, переменной x присваивалось значение а переменой , которым, соответственно, присваивались значения переменных проекта то после выполнения функции полученное значение z присваивается переменной а потом переменной проекта То есть ил = ПрЩ",

_ „ «з = /(^^зХ ПрП3 = «з • и2 = ПрП2;

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

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

Структура формальной модели проекта

Каждый проект в данной системе описывается множеством проектных операций и проектных параметров:

Пр = {ПрО, ПрП}, где                              – множест во проектных параметров;

– множество проектных операций.

Каждая проектная операция описывается множеством операций и множеством параметров:

ПрО = {О; ВхЩ ВыхП}, где                    – множество входных проектных параметров;

– множество выходных проектных параметров;

– множество всех проектных операций.

Каждая проектная операция представляет собой набор некоторых процедур, которые обрабатываются процессорами определенного типа: текстовым; табличным; математическим; интерактивного ввода данных; геометрическим; обработки ветвлений (условий). В соответствии с типами процессоров                       – совокупность всех типов операций.

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

Структура формального представления ветвлений

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

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

Операция ветвления описывается как

F^ax ; t?2... ^д/) — ПрОх оПр СР <л«ПрО3 о

ПрО4 и... u HpON ) n (npON+l и npON+2 VJ

.

При получении конкретного решения функция F^ах а^... а^ ) примет один из двух соответствующих видов:

F(aY; а2 ... aN) = ПрОх и ПрО2 о ПрО, vj

ПрОд vj...vjIIpON , или

Таким образом,сохраняя решение вместе с ветвями решений (условиями),можно сохранить несколько вариантов исполнения технического объекта.

Заключение

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

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

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

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

Список литературы Структура формального представления процесса проектирования в функционально адаптированной САПР

  • Roberta Charlton CAD interoperability problem still exists//Kubotek USA, news_events/press_releases/pr_08_01_2005.html' TARGET='_new'>http://www.kubotekusa.com/>news_events/press_releases/pr_08_01_2005.html
  • Хэмилтон П. Азбука технологий моделирования в MCAD-системах. Часть III. Как технологии MCAD влияют на процесс разработки изделия//CAD/CAM/CAE Observer. №2 (38), 2008. -C. 34-36.
  • Pokhil'ko A.F., Maslyantcin A.A. Toolkit for Support of the Process Approach for an Automated Workplaceof the engineer-designer//Interactive Systems: The Problems of Human. Computer Interaction. Ulyanovsk: USTU, 2003. -P. 29-37.
  • Горбачев И.В., Похилько А.Ф. Анализ функциональности модели технического объекта при построении систем проектирования//Труды XII МНПК «Системный анализ в проектировании и управлении». Ч. 2. СПб: Изд. СпбПТУ, 2008. -С. 229-233.
  • Похилько А.Ф., Маслянцын А.А., Скворцов А.В., Удовиченко А. В. Формальное представление процесса проектной деятельности в инструментальной инфокоммуникационной среде САПР//Инфокоммуникационные технологии. Т.6., №1, 2008. -С. 80-83.
  • Похилько А.Ф., Маслянцын А.А., Удовиченко А.В., Куприянов А.А. Формализация и анализ процессов проектирования технических объектов//Автоматизация процессов управления. Интегрированные АСУ. №2 (8), 2006. -С.132-
Еще
Статья обзорная