Udo Szczepanek, Karl-Heinz Roediger - Простая САПР, основанная на ограничениях

Аннотация

Udo Szczepanek, Karl-Heinz Roediger. Простая система САПР, основанная на ограничениях. В этой статье описывается САПР-система, основанная на последовательном решателе ограничений. Решатель использует скрипт, который хранит все действия, выполненные пользователем для создания конструкции и управления ею. Помимо решения ограничений, этот метод дает возможность реализовать очень полезные функции, такие как отмена и повтор, простое повторное использование конструкций и ретроактивное изменение процесса строительства. Система была разработана в качестве исследовательского проекта в Бременском университете (Щепанек, 2003).

1. Введение

Различные опросы показали, что новое строительство в настоящее время составляет лишь небольшую долю строительных работ. Большая часть конструкций, выполняемых в промышленности, - это просто модификация уже существующих решений (Schafer and Roller, 2002). Даже в новых конструкциях в среднем только 20% деталей действительно новые; 40% используются повторно, а еще 40% адаптированы (Schafer and Roller, 2002). Поэтому полезно иметь параметризованное и гибкое описание конструкции (Schafer and Roller 1998). Это может быть предложено САПР-системами, основанными на ограничениях.

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

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

2. Состояние творчества

Для параметризации конструкций были разработаны так называемые модельеры ограничений. Ограничения используются для определения определенных геометрических и топологических ограничений. Ограничения дают возможность описывать конструкции таким образом, чтобы они были параметризованы и могли использоваться повторно. Чтобы определить конкретную геометрию из множества ограничений (так называемая система ограничений), она должна быть распущена. Это основная проблема при реализации САПР на основе ограничений (Spur and Krause, 1997). Для устранения систем ограничений существует несколько различных методов (Roller, 1995). Первый - численный метод - был реализован в Sketchpad (Sutherland, 1963). Ограничения переносятся в математические уравнения и затем решаются с помощью процедуры аппроксимации (Light and Gossard, 1982). В рамках метода символического решения ограничения также переносятся в математические уравнения. Но они решаются с использованием символических алгебраических методов (Buchanan and de Pennington, 1993).

Другой возможностью являются методы, основанные на правилах, которые последовательно определяют координаты точек топологии, снабженной ограничениями, с помощью экспертной системы (Sunde, 1986). Топология и ограничения представляют факты в этом методе, из которых решение или факты на более высоком уровне выводятся с помощью соответствующих правил.

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

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

Finne and Takala (1991) разработали более старый подход, ориентированный на процесс. Они понимают историю конструирования как описание создания компонента. Разработанная ими система METAVIEWS основана на нециклично-ориентированном графе транзакций. Каждая транзакция определяется операцией, а также входами и выходами, где выходы транзакции могут быть входами других транзакций. График неявно описывает компонент тем способом, при котором сохраняются все транзакции, необходимые для его создания.

3. Принцип скриптов

Для реализации последовательного решателя ограничений был разработан принцип скриптов. Это смесь подхода, используемого в METAVIEWS, и метода решения порождённых ограничений (Finne and Takala, 1991). Идея METAVIEWS была адаптирована для хранения отдельных операций, включая их ввод и вывод, в виде ограниченных и идентифицируемых единиц. Как и при решении порождённых ограничений, сохраненные операции позже используются для повторения процесса построения с измененными параметрами и, следовательно, для реализации конструкций с другой параметризацией. Кроме того, был разработан механизм, который позволяет визуализировать историю конструирования на разных языках.

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

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

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

4. Реализация метода

Для реализации создания объектов и манипулирования ими, а также разделения скрипта на отдельные рабочие объекты, включающие связанные данные, скрипт COAT (CAD and Office Applications for the Tailors Trade - САПР и Офисные Приложения для Портных) содержит две группы языковых конструкций, которые допускают две точки зрения на сценарий. Первая точка зрения - это инженерный чертеж. Поскольку весь процесс проектирования записывается, можно показать чертеж на каждом этапе. Вторая точка зрения состоит из последовательного описания отдельных шагов работы в виде обычного текста. Он указывает, какие объекты были изменены и каким образом.

Рисунок 1 - Структура сценария процесса конструирования

Рисунок 1 - Структура скрипта(сценария) процесса конструирования

Чтобы реализовать упомянутые точки зрения, сценарий процесса конструирования состоит из последовательности Work_steps (см. рис. 1). Каждый из блоков состоит из ведущего описания (Descr_block) и нескольких конструкционных блоков (Constr_block). Start_struct может заменить только первый блок скрипта. Структуры описания используются для создания простой текстовой документации, в то время как структуры построения позволяют повторять процесс построения и, следовательно, создавать чертеж. Последний может заключать в себе одну или несколько строк в зависимости от типа операции.

Рисунок 2 - Начало скрипта(сценария) конструирования

Для новой конструкции сценарий начинается с начальной структуры (см. рис. 2, строка 1), которая инициализирует структуру данных для чертежа САПР. Если это касается продолжения или модификации существующей конструкции, эта инструкция опускается, и сценарий начинается со строительного блока, который ссылается на основную конструкцию (см. рис. 3, строки 1 и 2). Структура описания всегда содержит инструкцию "WorkStep" (см. рис. 1). Переданное целое число представляет идентификатор текстового шаблона, который используется для создания текстового представления конструкции история. Переданная строка содержит идентификаторы используемых параметров в виде обычного текста.

Рисунок 3 - Сценарий загрузки базового шаблона и продолжения конструирования

В блоке описания параметры операции могут отображаться в другой форме, чем в блоке построения. На рисунке 2 это относится к измеряемой длине в строке 2, показанной в виде MZ1241M (строка 5). В скрипте показатели отображаются только в закодированном виде, поскольку имена параметров могут содержать пробелы и специальные символы. Для интерпретатора пробел в имени нельзя отличить от пробела, который отделяет имя от следующей структуры. Параметры кодируются на основе их идентификатора в базе данных. Параметр "Длина", упомянутый выше, имеет идентификатор 1241.

Рисунок 4 - Диалоговое окно параметров для этапа конструирования "Угловая линия"

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

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

Затем у пользователя есть возможность параметризовать функцию. Параметры можно выбрать из списков, ввести напрямую или с помощью перетаскивания. Параметры, показанные на рисунке 4, означают, что в точке Точка бедра на Базовой линии линия длиной Измерение бедра/2 + 2 см проводится вправо под углом 90°. Новая линия получит название Hip line. В области предварительного просмотра в правой части окна показан результат работы функции.

Для генерации строк скрипта на основе параметров, заданных пользователем, используются текстовые шаблоны. Для этапа построения используются по меньшей мере два шаблона: один для блока описания и один или несколько для блока построения (см. рис. 1). Шаблоны заполняются вводимыми данными пользователя и передаются интерпретатору COAT. В зависимости от конфигурации временные объекты создаются для предварительного просмотра диалогового окна, или графические объекты изменяются на чертеже, или создаются новые. Шаблоны и результирующие строки скрипта из приведенного выше примера показаны на рисунке 5.

Рисунок 5 - Шаблон и итоговые строки скрипта

Первый шаблон (строка 1) описывает упомянутую выше структуру WorkStep, которая будет заполнена идентификатором шаблона обычного текста и строкой с параметрами; результат показан в строке 4. Вторая строка немного более комплексная; она содержит команды скрипта, которые используются для создания угловой линии. Слева от знака равенства должно быть указано название линии (строка 5). В качестве первого параметра задается начальная точка новой линии, здесь верхний конец базовой линии (Root.Pattern_part1.Line1[0]). Затем определяется вектор направления базовой линии (.Direction) и поворачивается на величину, указанную в диалоговом окне (.Rotate(...)), чтобы получить направление новой линии. В конце указывается длина новой линии (M1153M / 2 + 2 см). Формула, приведенная в диалоговом окне, передается непосредственно в скрипт; кодируется только используемая мера.

5. Преимущества принципа скриптов

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

Для примера могут быть сгенерированы следующие тексты:

Eine Linie von 'Base line (Pattern part1)' in einem Winkel von 270° und einer Lange von Hm / 2 + 2cm abwinkeln.

Draw a line from ''Base line (Pattern part1)'. Use an angle of 270° and a length of Hm / 2 + 2cm.

Disegna una linea del ''Base line (Pattern part1)' con angolo di 270° e lunghezza Hm / 2 + 2cm.

Провести линию от ''Base line (Pattern part1)' под углом 270° длиной Hm / 2 + 2cm.

Однако приведенный выше пример также показывает некоторые проблемы. Таким образом, имена, указанные пользователем, не переводятся (например, Base line). Кроме того, могут отображаться идентификаторы, заданные системой, такие как Pattern part1 или Line2, которые не очень выразительны. Тем не менее, чтобы иметь возможность идентифицировать объект, был реализован механизм, который выделяет объект на чертеже при нажатии на соответствующий идентификатор. Другая проблема заключается в том, что названия измерений (например, Hm для Измерения бедер) не переводятся. Это может быть решено с помощью идентификаторов для меры также в блоке описания (в данном случае M1153M для Hm).

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

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

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

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

Рисунок 6 - Редактор истории конструирования

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

С помощью редактора историю конструирования можно просмотреть на несколько шагов вперед или назад. Кроме того, можно перейти непосредственно к этапу конструирования. Чертеж конструкции всегда отражает состояние последнего выполненного шага. Кроме того, есть возможность автоматического просмотра истории, так называемого воспроизведения конструкции.

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

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

Некоторые ошибки возникают только при определенных параметрах, например, если линия недостаточно длинная, чтобы пересекать другую. Чтобы распознать такие проблемы уже во время генерации, конструкция в системе COAT может быть выполнена с различными наборами параметров одновременно. Вместо одной в памяти хранится несколько конструкций. Затем каждая операция выполняется для всех вариантов. Если в одном из вариантов возникает ошибка, пользователь получает предупреждение. Один из вариантов показан разработчику для взаимодействия в пользовательском интерфейсе, и он может переключаться туда и обратно между различными параметризациями в любое время

6. Применение

Ниже описаны два примера использования системы COAT. Выкройка части пальто на рис. 7 показывает гибкость конструкций, созданных с помощью системы. Обе версии являются результатом одного и того же сценария построения, следовательно, одного и того же процесса построения. Они просто имеют разные параметры: размер 32 (слева) и размер 42 (справа). Кроме того, были использованы различные значения для ширины, длины и нижней точки реверса. Чтобы получить такую гибкую конструкцию, на этапах строительства использовались просто размеры корпуса и обратные параметры.

Рисунок 7 - Выкройка части пальто с разными параметрами

Это простой и эффективный способ конструирования, а получаемые в результате конструкции очень гибкие. Более того, при построении пользователь может решить, насколько гибким должен быть шаблон, выбрав фиксированные значения или переменные. Чем больше создается переменных, тем больше различных версий конструкций может быть сгенерировано с разными параметрами.

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

Рисунок 8 - Сравнение ошибочной и правильной частей шаблона

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

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

Заключение

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

Список литературы

1. Buchanan, S.A. and A. de Pennington: Constraint Definition System: A Computer-Algebra Based Approach to Solving Geometric-Constraint Problems, Computer Aided Design 25 (1993) 10, pp. 741-750.
2. Finne, Ch. and T. Takala: Experimenting the MetaViews System in Architectural Design Office in: Burman, Chr., et al., Tools and Information Systems. Aesthetically Qualified Environment and New Planning Techniques, Part3. Technical Research Centre of Finland, Research Notes 1236, 1991. pp. 180-194.
3. Kondo, K.: PIGMOD: Parametric and Interactive Geometric Modeller for Mechanical Design, Computer Aided Design 22 (1990) 10, pp. 633-644.
4. Light, R. and D. Gossard: Modification of geometric models through variational geometry, Computer Aided Design 14 (1982) 4, pp. 209-214.
5. Paul, H.: Exploratives Agieren - Ein Beitrag zur ergonomischen Gestaltung interaktiver Systeme, Frankfurt 1995.
6. Roller, D.: CAD: effiziente Anpassungs- und Variantenkonstruktion, Berlin 1995.
7. Schafer, D. and D. Roller: Parametrische Produktund Proze?modellierung, CAD-CAM Report 17 (1998) 10, pp. 74-84.
8. Schafer, D. and D. Roller: Entwicklung eines Variantenmoduls fur Elektro-CAD Systeme der nachsten Generation, in: Roller, D. (ed.): Jahresbericht 2000/2001, Lehrstuhl Grundlagen der Informatik, Graphische Ingenieursysteme, Universitat Stuttgart, Stuttgart 2002.
9. Spur, G. und F.-L. Krause: Das virtuelle Produkt: Management der CAD-Technik, Munchen 1997.
10. Sunde, G.: Specification of shape by dimensions and other geometric constraints, in: Wozny, M.J., W. McLaughlin, and J. Encarnacao (eds.): Geometric Modeling for CAD Applications, Amsterdam 1986, pp. 199-213.
11. Sutherland, I.: Sketchpad - a man-machine graphical communication system, PhD Thesis, MIT, Cambridge, MA 1963.
12. Szczepanek, U.: Konzeption und Entwicklung eines proze?orientierten CAD-Systems fur die Bekleidungs konstruktion, Aachen 2003.
13. Widmer, H.-J. und U. Weber (Red.): Aktueller Stand der CAD-Technik und der rechnergestutzten Konstruktionsarbeit, Zwischenbericht BMFTVerbundprojekt CAD-Referenzmodell, Karlsruhe 1993.
14. Zetzsche, T.: Rechnerunterstutzung des Entwurfsprozesses durch funktional-technische Objektmodellierung, Dissertation, Dresden 2000.