Исследование механизмов построения интегрированной инструментальной среды на базе КОМПАС-3D

 

Министерство образования и науки Российской Федерации

Государственное образовательное учреждение

высшего профессионального образования

Ульяновский Государственный технический университет

Факультет: Радиотехнический

Кафедра: САПР

Диссертация на соискание степени магистра техники и технологии

Исследование механизмов построения интегрированной инструментальной среды на базе КОМПАС-3D

Направление: 21020068 "Проектирование и технология электронных средств"

(магистратура) программа "Информационные технологии в проектировании электронных средств"

Кожевников Михаил Олегович

Научный руководитель

к.т.н., профессор А.Ф. Похилько

Ульяновск 2010 г.

УДК 658.512.22

Рецензент

Аннотация

. Название: «Исследование механизмов построения интегрированной инструментальной среды на базе КОМПАС-3D»

. Год завершения работы - 2010

. Объем работы: ___ с.

. Количество приложений: 4

. Количество иллюстраций: 44

. Количество таблиц: 6

. Количество источников литературы: 41

Характеристика работы:

1.Цель научной работы:

Повысить эффективность математической поддержки проектирования в системе КОМПАС-3D путём интеграции данного продукта с математическим пакетом MathCAD в рамках интегрированной инструментальной среды. Для этого необходимо реализовать Модули интеграции для обоих продуктов, которые позволят организовать обмен данными с внешними приложениями, а так же создать демонстрационный модуль интегрированной САПР, который позволит решить проблему хранения и повторного использования ранее разработанных проектов.

2.Методы проведенных исследований

Теория систем, теория множеств, теория баз данных, формальная логика.

3.Основные результаты научного исследования (научные, практические)

Получен демонстрационный программный модуль реализующий цели научной работы.

4.Наличие документа об использовании научных результатов - нет

Кожевников М.О.

Оглавление

Введение

1. Обзор методов повышения уровня автоматизации проектирования

1.1 Направления развития САПР

1.1.1 Интеллектуализация САПР

1.1.2 Параметризация.

1.1.3 Интеграция САПР

1.1.4 Комплексная автоматизация подготовки производства

1.2 Технологии интеграции инструментальных приложений

1.2.1 От OLE к ActiveX

1.2.2 Понятие COM, принципы работы

1.2.3 Обзор технологий ActiveX и OLE

1.2.4 NET и будущее COM

1.2.5 Универсальный формат обмена XML

1.3 Возможности КОМПАС-3D

1.4 Автоматизация инженерных расчётов

1.5 Выводы

2. Графический процессор ИИС

2.1 Интегрированная Инструментальная Среда

2.2 Технологии интеграции инструментальных приложений

2.2.1 Компас-3D как Графический процессор ИИС

2.2.2 Схема взаимодействия Графического процессора с компонентами интегрированной инструментальной среды

2.2.3 Схемы взаимодействия КОМПАС-3D и MathCAD на основе доступных механизмов интеграции

2.3 Модель данных и иерархическая структура функций ИИС

2.4 Выводы

3. Программная реализация

3.1 Выбор средств разработки приложений

3.2 Выбор СУБД и разработка структуры базы данных

3.3 Разработка Интерфейсных модулей

3.3.1 Разработка Интерфейсного модуля для КОМПАС-3D

3.3.2 Разработка Интерфейсного модуля для MathCAD

3.3.3 Разработка механизма связывания переменных

3.4 Разработка графического интерфейса пользователя ИИС

3.5 Выводы

4. Апробация программного решения

4.1 Пример проектирования ребристого радиатора в ИИС

4.2 Пример проектирования шпоночной протяжки в ИИС

4.3 Выводы

Заключение

Литература

Приложение 1

Приложение 2

Приложение 3

Приложение 4

Введение

Современные САПР имеют в своем арсенале большое количество средств. В области трехмерного моделирования все приложения обладают примерно одинаковым набором инструментов. Также все САПР имеют поддержку современных стандартов представления моделей (STEP, IGES и т. п.), позволяют использовать сквозной цикл проектирования, отображать дерево построения детали. Что касается инструментов параметризации, здесь тоже все приложения находятся на достаточно высоком уровне, большинство из них могут производить ассоциативные изменения в сборках при изменении одного из компонентов.

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

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

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

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

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

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

Решение вышеперечисленных проблем состоит в построении такой системы, которая, в рамках интегрированной инструментальной среды, обеспечила бы: обработку данных в специализированных приложениях; простые механизмы обмена данными между различными приложениями; поддержку инструментов хранения и передачи готовых проектных решений, а также инструментов для их модификации. Ключевым элементом интегрированной инструментальной среды, безусловно, стоит признать Графический процессор. Именно от свойств этого компонента, его механизмов интеграции во многом будет зависеть возможность построения такой среды. Но не менее важным элементом ИИС является Математический процессор - без полноценной математической поддержки сложно представить себе современный процесс проектирования.

Поэтому цель данной работы можно сформулировать следующим образом:

Повысить эффективность математической поддержки проектирования в системе КОМПАС-3D путём интеграции данного продукта с математическим пакетом MathCAD в рамках интегрированной инструментальной среды.

Достижение поставленной цели потребует решения ряда задач:

·Исследовать структуру ИИС.

·Сформулировать требования, предъявляемые к Графическому процессору в интегрированной инструментальной среде.

·Исследовать возможности и особенности работы систем КОМПАС-3D и MathCAD.

·Исследовать доступные в КОМПАС-3D и MathCAD механизмы интеграции и инструменты для расширения их возможностей.

·Исследовать возможные схемы взаимодействия КОМПАС-3D и MathCAD на основе доступных механизмов интеграции.

·Разработать структуру базы данных для сохранения результатов проектной деятельности.

·Разработать Интерфейсные модули для КОМПАС-3D и MathCAD.

·Разработать программный модуль, реализуйщий основные возможности Управляющего модуля ИИС.

·Разработать Графический интерфейс пользователя ИИС.

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

1.Обзор методов повышения уровня автоматизации проектирования

.1Направления развития САПР

1.1.1Интеллектуализация САПР

Стремительное распространение в нашей стране персональных компьютеров сопровождалось не менее стремительным потоком импортных САПР. Все эти системы объединяет одно свойство: крайне низкий уровень их "интеллектуального" развития. Они не способны самостоятельно принять ни одного технического решения и в руках инженера, принимающего все решения, являются не более чем усовершенствованным электронным кульманом. Все богатство инженерных знаний остается в книгах и, по мере способностей и опыта, в человеческих головах [7].

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

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

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

Принципиальное отличие интеллектуальных систем автоматизированного проектирования видится в том, что в качестве исходной информации выступают технические требования к изделию и знания о методах его проектирования, основанные на его функциональном назначении и опыте эксперта. Графический образ изделия появляется (а чаще просто генерируется) позже. Само понятие интеллектуальной САПР говорит о явном присутствии в системе знаний, т.е. о возможности на каком-либо уровне принимать решения без участия проектировщика. Такая возможность может быть обеспечена путем перехода от построения системы проектирования по алгоритмическому принципу работы САПР, на методику объектно-ориентированного подхода. При таком подходе объект проектирования (точнее, его информационная модель) по мере проектирования непрерывно изменяет состояние вплоть до окончания процесса. Объектный подход имеет следующие преимущества [2]:

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

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

1.1.2Параметризация

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

Параметрическое моделирование существенно отличается от обычного двухмерного черчения или трёхмерного моделирования <#"justify">Двухмерное параметрическое черчение и моделирование.

Параметризация двухмерных чертежей обычно доступна в CAD <#"justify">Трёхмерное твердотельное параметрическое моделирование.

Трёхмерное параметрическое моделирование является гораздо более эффективным (но и более сложным) инструментом, нежели двухмерное параметрическое моделирование. В современных системах среднего и тяжёлого класса наличие параметрической модели заложено в идеологию самих САПР <#"justify">Типы параметризации:

ØТабличная параметризация

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

Однако, табличная параметризация находит широкое применение во всех параметрических САПР <#"justify">ØИерархическая параметризация

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

Помимо «дерева построения» модели, система запоминает не только порядок её формирования, но и иерархию её элементов (отношения между элементами). (Например: сборки -> подсборки -> детали).

Параметризация на основе истории построений присутствует во всех САПР <#"justify">ØВариационная (размерная) параметризация

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

Процесс создания параметрической модели с использованием вариационной параметризации выглядит следующим образом:

• На первом этапе создаётся эскиз (профиль) для трёхмерной операции. На эскиз накладываются необходимые параметрические связи.
• Затем эскиз «образмеривается». Уточняются отдельные размеры профиля. На этом этапе отдельные размеры можно обозначить как переменные (например, присвоить имя «Length») и задать зависимости других размеров от этих переменных в виде формул (например, «Length/2»)
• Затем производится трёхмерная операция (например, выталкивание), значение атрибутов операции тоже служит параметром (например, величина выталкивания).
• В случае необходимости создания сборки, взаимное положение компонентов сборки задаётся путём указания сопряжений между ними (совпадение, параллельность или перпендикулярность граней и рёбер, расположение объектов на расстоянии или под углом друг к другу и т. п.).

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

ØГеометрическая параметризация

Геометрическая параметризацией называется параметрическое моделирование, при котором геометрия каждого параметрического объекта пересчитывается в зависимости от положения родительских объектов, его параметров и переменных.

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

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

Процесс создания параметрической модели методом геометрической параметризации выглядит следующим образом:

• На первом этапе конструктор задаёт геометрию профиля конструкторскими линиями, отмечает ключевые точки.
• Затем проставляет размеры между конструкторскими линиями. На этом этапе можно задать зависимость размеров друг от друга.
• Затем обводит конструкторские линии линиями изображения - получается профиль, с которым можно осуществлять различные трёхмерные операции.

Последующие этапы в целом аналогичны процессу моделирования с использованием метода вариационной параметризации.

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

1.1.3Интеграция САПР

Интеграция ПО базируется на идеях объектно-ориентированного программирования. Следует различать синтаксический и семантический аспекты интеграции. Синтаксическая интеграция реализуется с помощью унифицированных языков и форматов данных, технологий типа ODBC для доступа к общему банку данных или компонентно-ориентированных (CBD - Component-Based Development) технологий. Семантическая интеграция подразумевает автоматическое распознавание разными системами смысла передаваемых между ними данных и достигается значительно труднее. Для создания ПО САПР, так же как и других сложных автоматизированных информационных систем, определяющее значение имеют вопросы интеграции ПО. Теоретической базой для создания технологий интеграции ПО в САПР являются:

• методология автоматизированного проектирования, в соответствии с которой осуществляются типизация проектных процедур и маршрутов проектирования в различных предметных областях, выявление типичных входных и выходных данных процедур, построение информационных моделей приложений и их обобщение, сравнительный анализ альтернативных методов и алгоритмов выполнения типовых процедур;
• объектно-ориентированная методология, в соответствии с которой множества сущностей, фигурирующих в процессах проектирования, подразделяются на классы, в классах появляются свои процедуры и типы данных с отношениями наследования. Эти классы могут быть инвариантными и прикладными. Их обобщение и унификация приводят к появлению таких понятий и средств, как интегрированные ресурсы и прикладные протоколы, фигурирующие в стандартах STEP, или унифицированные программные компоненты типа графических ядер конструкторских САПР. Именно наличие типовых процедур и единообразное толкование атрибутов объектов в рамках конкретных протоколов позволяют разным программным системам «понимать» друг друга при взаимодействии.

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

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

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

Прикладные протоколы STEP представляют семантическую сторону интеграционных технологий. Для интеграции нужна не только унификация моделей приложений, но и унификация механизмов взаимодействия, примерами которых являются технологии OLE, DDE, а также компонентно-ориентированные технологии.

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

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

В операционных системах Microsoft для организации межпрограммных взаимодействий были предложены средства Clipboard, DDE, OLE и в дальнейшем технология ActiveX.

1.1.4Комплексная автоматизация подготовки производства

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

На чем же должна основываться комплексная автоматизация подготовки производства? Очевидно, что структура предприятия и его информационные ресурсы, это очень важно. Но как же насчет самого изделия? Существует иллюзия, что если технологическая система получит некоторые данные от конструкторской системы, то все остальное получится само. Ничего само не получится. Конструкторско-технологическая подготовка производства - это сложный процесс, автоматизация которого может основываться только на совокупности информации как о структуре служб подготовки производства, так и на информации об изделии, включая его состав, структуру и свойства, ассоциативные связи между его составными частями, а так же на данных о текущем состоянии процесса подготовки производства [15].

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

Вместе с окончанием революционного этапа развития средств геометрического моделирования приходит осознание того, что даже самая совершенная параметризованная геометрическая модель не может являться "несущей конструкцией" для построения комплексных систем подготовки производства просто по причине ее несоответствия этой цели [32].

Какое же место занимает геометрическая модель в представлении изделия для комплексной автоматизации подготовки производства? Это только одно из свойств изделия.

Таким образом, для комплексного решения задачи автоматизации необходима некоторая интегрирующая среда, управляющая процессом подготовки производства на основе:

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

Очевидно, что все эти аспекты взаимосвязаны. Проблема состоит в том, что разработанная и успешно внедренная система оказывается привязанной к конкретному предприятию и узкому классу изделий. Следствие - полная непригодность к тиражированию и высокая стоимость развития.

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

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

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

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

Каждый объект характеризуется некоторым набором свойств и составляющих его компонентов - вложенных объектов.

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

Такие цепочки импорта-экспорта свойств и являются связями, обеспечивающими совместимость элементов конструкции.

Что дает такая организация модели? На первый взгляд одни и те же свойства многократно дублируются в дереве объектов (каждое свойство однажды экспортируется и многократно импортируется). Однако такой механизм делает каждый объект независимым и самодостаточным. Если некоторые свойства характеризуют объект, но не определяются им (импортируемые свойства), то они являются исходными данными для определения других свойств объекта (внутренних или экспортируемых). Каждый объект связан с внешним миром (моделью) импортируемыми - экспортируемыми свойствами и только.

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

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

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

Для интеграции локальных САПР в комплексную систему автоматизации необходимо обеспечить наличие в них средств доступа к свойствам информационной модели изделия [15,32].

1.2Технологии интеграции инструментальных приложений

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

Можно сказать, что история программирования - это история попыток написать совершенный код. Разработка как прикладного, так и системного программного обеспечения страдала от бесконечных проволочек, а сами программы отличались умопомрачительной сложностью и непредсказуемым количеством жучков. И все же без программ не обойтись, но как написать хорошую программу? Для этого нужно обладать способностью соединить общие принципы программного проекта с желанием (и даже горячим стремлением) вникнуть в миллиарды мелочей. Это требует не только колоссальных интеллектуальных усилий, но и соответствующего инструментария, который, увы, все еще далек от совершенства., ActiveX, COM, .NET фирмы Microsoft - еще на один шаг приближают нас к более совершенным, т.е. более надежным и эффективным, программам. Но не только: более совершенные программы должны делать то, что раньше было невозможно, т.е. решать новые проблемы. В основе этих технологий лежит очень простая идея, но, как оказалось, она позволяет существенно повысить эффективность программирования.

1.2.1От OLE к ActiveX

Первоначально OLE была задумана как технология интеграции программных продуктов, входящих в комплект Microsoft Office. Предшественницей OLE является реализованная в Windows технология динамического обмена данными DDE (Dynamic Data Exchange), до сих пор широко применяемая в данной среде. Однако многие разработчики не без оснований считают, что DDE трудно использовать, поскольку это технология низкого уровня. По существу, DDE представляет собой модель взаимодействия процессов - протокол, с помощью которого приложение может организовать канал обмена данными с DDE-сервером, находящимся на той же машине. DDE - это асинхронный протокол. Иными словами, после установления связи вызывающая сторона передает запрос и ожидает возврата результатов. Такой механизм более сложен, чем синхронный вызов функции, так как нужно учитывать вероятность нарушения связи, тайм- ауты и другие ошибки, которые приложение должно распознавать и исправлять. Низкая популярность DDE вынуждала Microsoft искать различные способы его усовершенствования. Для упрощения наиболее сложных аспектов протокола была предложена спецификация DDEML, но этого оказалось недостаточно.

Несмотря на различия между низкоуровневой технологией системных объектов и средствами интеграции компонентов высокого уровня, Microsoft попыталась предоставить разработчикам объединенное решение. В качестве технологии более высокого уровня была реализована OLE 1.0 OLE 1 (Object Linking and Embedding - связывание и внедрение объектов). Она расширила возможности протокола DDE и, используя его как базовый механизм коммуникаций, позволила активизировать встроенный объект в документе, т. е. получить составной документ. Таким образом, OLE 1.0 унаследовала многие проблемы асинхронного протокола. Эта технология имела множество недостатков, а ее компоновка была слишком сложна для пользователей среднего уровня. Кроме того, установленные связи легко нарушались, например, в результате изменения маршрута доступа к файлу связанного объекта.

Первое воплощение OLE - OLE 1 - представляло собой механизм создания и работы с составными документами (compound documents). С точки зрения пользователя, составной документ выглядит единым набором информации, но фактически содержит элементы, созданные двумя или несколькими разными приложениями. С помощью OLE 1 пользователь мог, например, объединить электронную таблицу, созданную Microsoft Excel, с текстовым документом производства Microsoft Word. Идея состояла в том, чтобы документо-ориентированная (document-centric) модель работы с компьютером позволила бы пользователю больше думать об информации и меньше - о приложениях, ее обрабатывающих. Как следует из слов связывание и внедрение, составные документы можно создать, либо связав два разных документа, либо полностью внедрив один документ в другой.1, как и большинство первых версий программных продуктов, была несовершенна. Архитекторам следующей версии предстояло улучшить первоначальный проект. Вскоре они поняли, что составные документы - лишь частный случай более общей проблемы: как разные программные компоненты должны предоставлять друг другу сервисы? Для решения этой проблемы архитекторы OLE создали группу технологий, область применения которых гораздо шире составных документов. Основу OLE 2 составляет важнейшая из этих технологий - Модель многокомпонентных объектов (Component Object Model - СОМ). Новая версия OLE не только обеспечивает поддержку составных документов лучше, чем первая, но и несомненно идет куда дальше простого объединения документов, созданных в разных приложениях. OLE 2 позволяет по-новому взглянуть на взаимодействие любых типов программ.

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

Благодаря этим преимуществам, СОМ скоро стал частью технологий, не имеющих никакого отношения к составным документам. Однако в Microsoft хотели сохранить общее имя для всей группы технологий, в основе которых лежит СОМ. Компания решила сократить название Object Linking and Embedding до OLE - эта комбинация более не рассматривалась как аббревиатура - и опустить номер версии.

В начале 1996 года Microsoft ввела в оборот новый термин - ActiveX. Сначала он относился к технологиям, связанным с Интернетом, и приложениям, выросшим из него, вроде WWW (World Wide Web). Поскольку большинство разработок Microsoft в данной области было основано на СОМ, то и ActiveX была непосредственно связана с OLE. Однако очень скоро новый термин стал захватывать территории, традиционно принадлежавшие OLE, и вот теперь все вернулось на круги своя: OLE, как встарь, обозначает только технологию создания составных документов связыванием и внедрением, а разнообразные технологии на основе СОМ, ранее объединенные под именем OLE, собраны под знаменем ActiveX. А некоторые технологии, название которых содержало слово "OLE" даже перекрестили: теперь это технологии ActiveX. Новые технологии на основе СОМ, которым раньше полагался ярлык "OLE", теперь частенько получают пометку "ActiveX".

1.2.2Понятие COM, принципы работы

Все технологии OLE и ActiveX, построены на основании, обеспеченном СОМ. Чем занимаеться СОМ? Данная модель определяет стандартный механизм, с помощью которого одна часть программного обеспечения предоставляет свои сервисы другой, вне зависимости от их природы.

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

Большинство объектов СОМ поддерживают более одного интерфейса. Сам объект всегда реализуется внутри некоторого сервеpa. Сервер может быть либо динамически подключаемой библиотекой (DLL), подгружаемой во время работы приложения, либо отдельным самостоятельным процессом.

Чтобы вызывать методы интерфейса объекта СОМ, клиент должен получить указатель на этот интерфейс. Обычно СОМ-объект предоставляет свои сервисы посредством нескольких интерфейсов, и клиенту требуется отдельный указатель для каждого интерфейса, методы которого он намерен вызывать.

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

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

Благодаря СОМ, клиентам нет нужды учитывать данные отличия - доступ ко всему осуществляется единообразно. Для доступа к сервисам, предоставляемым любыми типами программного обеспечения, используется одна общая модель.

1.2.3Обзор технологий ActiveX и OLE

Как OLE, которая теперь снова обозначает только технологии создания составных документов, так и широкий набор технологий под маркой ActiveX, разработаны с использованием СОМ. Многие из этих технологий своими корнями уходят в поддержку составных документов, тогда как другие предназначены совершенно для других целей.

Автоматизация

Электронные таблицы, текстовые процессоры и другие программы предоставляют все виды полезных возможностей. Почему бы не обеспечить доступ к ним и другому программному обеспечению? Чтобы это стало возможным, приложения должны предоставлять свои сервисы не только человеку, но и программам - они должны быть программируемыми. Обеспечение программируемости и является целью Автоматизации (Automation, первоначально называвшейся OLE-автоматизацией).

Приложение можно сделать программируемым, обеспечив доступ к его сервисам через обычный СОМ-интерфейс. Однако так поступают редко. Вместо этого доступ к сервисам приложений осуществляется через диспинтерфейсы (dispinterface). Они очень похожи на интерфейсы, (у него есть методы, клиенты осуществляют к нему доступ через указатель интерфейса и т. д.), но имеют и существенные отличия. В частности, методы диспинтерфейса гораздо проще вызывать клиентам, написанным на простых языках типа Visual Basic. Это очень важно: ведь большинство людей, желающих писать программы, осуществляющие доступ к внутренним сервисам приложений, чаще всего выбирают Visual Basic и аналогичные среды.

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

Составные документы

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

Для решения этой проблемы предназначена технология OLE (ранее называвшаяся Документы OLE - OLE Documents). Поддерживая нужные СОМ-объекты, каждый с собственным набором интерфейсов, независимые приложения могут совместно работать, чтобы пользователь получил один составной документ. Все эти интерфейсы носят абсолютно общий характер - ни одно приложение не знает, что представляют собой другие. Зачем встраивать в текстовый процессор функции электронной таблицы? OLE поможет просто задействовать в случае необходимости существующее приложение электронной таблицы.

Определенный OLE стандартный интерфейс обеспечивает взаимодействие между приложениями любых типов и любых производителей, а не только между электронными таблицами и текстовыми процессорами Microsoft.

При создании составного документа с помощью OLE одно из приложений всегда является контейнером. Как следует из названия, контейнер определяет самый общий документ, в котором содержится все остальное. Другие приложения - серверы - могут размещать свои документы внутри документа-контейнера. При использовании OLE документ сервера может быть либо связан, либо внедрен в документ контейнера.

Управляющие элементы ActiveX

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

Первоначально управляющие элементы ActiveX были известны под названием управляющие элементы OLE или ОСХ. Microsoft изменила название, чтобы отразить некоторые новые возможности, сделавшие эти элементы более подходящими для Интернета и WWW. Например, управляющий элемент ActiveX может хранить свои данные на странице где-то в WWW либо может быть выкачан с сервера WWW и затем запущен на машине клиента. И контейнер, в котором работает управляющий элемент, не обязан быть средой программирования - вместо этого он может быть средством просмотра WWW.

Управляющие элементы ActiveX - не отдельные приложения. Напротив, они являются серверами, которые подключаются к контейнеру элементов. Как обычно, взаимодействие между управляющим элементом и его контейнером определяется различными интерфейсами, поддерживаемыми СОМ-объектами. Фактически управляющие элементы ActiveX используют многие другие технологии OLE и ActiveX. Например, управляющие элементы обычно поддерживают интерфейсы для внедрения и зачастую предоставляют доступ к своим методам через диспинтерфейсы Автоматизации.[41]

1.2.4.NET и будущее COM

В 2002 году <#"justify">1.2.5Универсальный формат обмена XML

Обсуждение XML не сходит со страниц большинства компьютерных изданий, а сам язык и его применение в сфере электронного бизнеса является "темой года". Такая популярность вполне заслужена - не только и не столько как собственно языка разметки электронных документов, но и как универсального формата для обмена электронными документами.

Наибольший интерес вызывает возможность организации обмена электронными документами между приложениям при помощи стандарта XML. В силу самоопределенности XML-документов, приложения могут передавать друг другу данные через XML-документы, не имея никакой дополнительной информации о струтктуре передаваемых данных. Дело в том, что приложения могут работать с XML-документами нормальным образом, не привлекая для этого соответствующий DTD (Document Type Definition), то есть в общем случае двум приложениям, чтобы понять один XML-документ, не нужно пользоваться каким-то общим DTD, задающим XML-документ. Как раз этот факт делает обмен документами между приложениями простым, гибким и надежным.[40]

XML (англ. <#"justify">Синтаксис XML

XML - это описанная в текстовом формате <#"justify">1.3Возможности КОМПАС-3D

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

Ключевой особенностью продукта является использование собственного математического ядра и параметрических технологий, разработанных специалистами АСКОН.

Основные компоненты КОМПАС-3D - собственно система трехмерного твердотельного моделирования, универсальная система автоматизированного проектирования КОМПАС-График и модуль проектирования спецификаций. Все они легки в освоении, имеют русскоязычные интерфейс и справочную систему.

Базовый функционал системы включает в себя:

• развитый инструментарий трехмерного моделирования, в том числе возможности построения различных типов поверхностей;
• механизм частичной загрузки компонентов и специальные методы оптимизации, позволяющие обеспечить работу со сложными проектами, включающими десятки тысяч подсборок, деталей и стандартных изделий;
• функционал моделирования деталей из листового материала - команды создания листового тела, сгибов, отверстий, жалюзи, буртиков, штамповок и вырезов в листовом теле, замыкания углов и т.д., а также выполнения развертки полученного листового тела (в том числе формирования ассоциативного чертежа развертки);
• специальные возможности, облегчающие построение литейных форм - литейные уклоны, линии разъема, полости по форме детали (в том числе с заданием усадки);
• инструменты создания пользовательских параметрических библиотек типовых элементов;
• возможность получения конструкторской и технологической документации: встроенная система КОМПАС-График позволяет выпускать чертежи, спецификации, схемы, таблицы, текстовые документы;
• встроенные отчеты по составу изделия, в том числе по пользовательским атрибутам;
• возможность простановки размеров и обозначений в трехмерных моделях (поддержка стандарта ГОСТ 2.052-2006 «ЕСКД. Электронная модель изделия»);
• поддержку стандарта Unicode;
• средства интеграции с различными CAD/CAM/CAE системами;
• средства защиты пользовательских данных, интеллектуальной собственности и сведений, составляющих коммерческую и государственную тайну (реализовано отдельным программным модулем КОМПАС-Защита).

По умолчанию КОМПАС-3D поддерживает экспорт/импорт наиболее популярных форматов моделей, за счет чего обеспечивается интеграция с различными CAD/CAM/CAE пакетами.

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

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

Простой интуитивно понятный интерфейс, мощная справочная система и встроенное интерактивное обучающее руководство «Азбука КОМПАС» позволяют освоить работу с системой в кратчайшие сроки и без усилий.[37]

1.4Автоматизация инженерных расчётов

Для автоматизации математических, инженерно-технических и научных расчётов используются разнообразные вычислительные средства - от программируемых микрокалькуляторов до сверхмощных суперЭВМ. И, тем не менее, такие расчёты для многих остаются сложным делом. Более того, применение компьютеров для расчётов внесло новые трудности: прежде чем начать расчёты, пользователь должен освоить азы алгоритмизации, изучить один или несколько языков программирования, а также численные методы расчётов. Положение существенно изменилось после выпуска специализированных программных комплексов для автоматизации математических и инженерно-технических расчётов.

К таким комплексам относятся пакеты программ Mathcad, MatLab, Mathematica, Maple, MuPAD, Derive и др. Mathcad занимает в этом ряду особое положение.[36] Связано это прежде всего с тем, что этот пакет задумывался как средство работы на компьютере пользователей, не желавших или не умевших возиться с языками программирования при решении финансовых, научно-технических и прочих прикладных задач (программирование без программирования).На практике, реализация такого подхода, приводит с следующей ситуации.

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

В то время как Maple, MATLAB и Mathematica - это языки программирования. Языки программирования гибкие и мощные, но трудные в использовании и требующие длительного времени на изучение. Поэтому, пользовательский интерфейс сложен, в нем легко допускать ошибки, которые вынуждают проверять и отлаживать весь код. Программирование не визуально и не интерактивно. Невозможно поменять несколько строк в программе и автоматически увидеть результаты. Для этого вам потребуется перекомпилировать и перезапустить программу. Также сложно разделить работу, а потом понять и использовать решения коллег. Не программисты не смогут снова использовать результаты. Даже если вы являетесь программистом, повторное использование чьих-то вычислений требует всестороннего инженерного анализа, чтобы понимать те процессы, которые скрываются за полученными результатами.[8]

Таким образом, благодаря простой и эффективной логике работы, а так же удобному пользовательскому интерфейсу, MathCAD можно признать оптимальным выбором, если речь идет об автоматизации инженерных расчётов. Рассмотрим возможности этого продукта подробнее.является интегрированной системой решения математических, инженерно-технических и научных задач. Он содержит текстовый и формульный редактор, вычислитель, средства научной и деловой графики, а также огромную базу справочной информации, как математической, так и инженерной, оформленной в виде встроенного в Mathcad справочника, комплекта электронных книг <#"235" src="doc_zip4.jpg" />

1. Принцип работы формульного процессора

Формульный процессор обеспечивает естественный «многоэтажный» набор формул в привычной математической нотации (деление, умножение, квадратный корень, интеграл, сумма и т.д.). Последняя версия Mathcad полностью поддерживает буквы кириллицы в комментариях, формулах и на графиках.

Вычислитель обеспечивает вычисление по сложным математическим формулам, имеет большой набор встроенных математических функций, позволяет вычислять ряды, суммы, произведения, интегралы, производные, работать с комплексными числами, решать линейные и нелинейные уравнения, а также дифференциальные уравнения и системы, проводить минимизацию и максимизацию функций, выполнять векторные и матричные операции, статистический анализ и т.д. Можно легко менять разрядность и базу чисел (двоичная, восьмеричная, десятеричная и шестнадцатеричная), а также погрешность итерационных методов. Автоматически ведётся контроль размерностей и пересчёт в разных системах измерения (СИ, СГС, англо-американская, а также пользовательская).

В Mathcad встроены средства символьной математики, позволяющие решать задачи через компьютерные аналитические преобразования.

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

1. Интеграция Mathcad и Pro/ENGINEER

О возможностях интеграции MathCAD говорит тот факт, что начиная с 14-й версии, Mathcad интегрирован с Pro/ENGINEER и с SolidWorks.

В основе интеграции MathCAD и Pro/ENGINEER (см. рис. 1.2) лежит двухсторонняя связь между этими приложениями. Их пользователи могут легко связать любой файл Mathcad с деталью и сборкой Pro/ENGINEER при помощи такой функции системы Pro/ENGINEER, как фичер анализа. Базовые величины, расчитанные в системе Mathcad, могут быть переведены в параметры и размеры CAD-модели для управления геометрическим объектом. Параметры из модели Pro/ENGINEER также можно ввести в Mathcad для последующих инженерно-конструкторских расчётов. При изменении параметров взаимная интеграция двух систем позволяет динамически обновлять вычисления и чертёж объекта.[36]

1. Интеграция Mathcad и SolidWorks

MathCAD Integrator (см. рис. 1.3) представляет собой программный модуль, который позволяет связывать между собой переменные двух продуктов. Он существенно уменьшает усилия пользователей, сокращает цикл разработки изделия, и снижает риск ошибок. Данная технология позволяет автоматически вести параметрическое моделирование в SolidWorks. [35,34]

Ниже приведен список доступных механизмов интеграции:

• Использование API-интерфейса, который предоставляет доступ к функциям математического ядра. Доступ к этим функциям можно получить из приложений, написанных на различных современных языках программирования. Наиболее важные методы: SetValue (задать значение входных переменных) и GetValue (считать значение выходных переменных).
• Использование технологии внедренных объектов. Так, например, в рабочий лист можно внедрить объекты Word, Excel, SolidWorks и др.
• Экспорт/импорт таблицы входных/выходных переменных посредством файла формата табличного редактора Excel - *.xls.
• Обработка, посредством синтаксического анализа, выходного файла, который c 12 версии представляет собой файл текстового формата - *.xmcd. Запись данных в этот файл производиться на особом «наречии» XML, который основан на собственном словаре. После изучения данного словаря можно получить доступ к обширному списку возможностей.

Из перечисленных механизмов интеграции, наиболее гибким стоит признать синтаксический анализ, а наиболее надежным API-интерфейс.

1.5Выводы

Анализ современного состояния рынка САПР показывает, что CAD - системы оказывают конструктору слабую помощь с точки зрения всего процесса конструкторского проектирования. Они обеспечивают описание геометрических форм и рутинные операции, такие как образмеривание, генерация спецификаций и т.п. Эти ограничения и чисто геометрический интерфейс оставляет методологию конструкторской работы такой же, какой она была бы при использовании кульмана. Системы автоматизации проектирования технологических процессов и программирования изготовления деталей на станках с ЧПУ подобно CAD - системам, не затронули сам процесс проектирования: САПР ТП - системы могут генерировать технологические процессы, но только при условии предварительного специального описания изделия с помощью конструкторско-технологических элементов. CAM-системой может быть использована геометрическая модель CAD-системы, но все функции САПР ТП - системы перекладываются на конструктора.

Реальные задачи проектирования не сводятся к «электронизации» накопленной инженерной документации. Это серьезный процесс согласованного труда инженеров, управленцев, программистов и т.д. Причем выпуск и передача документации на следующий этап - далеко не определяющая во всем цикле «проектирование - изготовление» составляющая.Главной составляющей автоматизированного проектирования должно являться создание такого информационного описания проектируемого изделия, которое позволяло бы уловить логику каждого проектного решения, оперативно осуществлять изменение проекта, использовать в дальнейшем полученные ранее проектные решения, даже относящиеся к другой области проектирования.

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

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

2.Графический процессор ИИС

2.1Интегрированная Инструментальная Среда

интеграция компас mathcad

Требования к ИИС

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

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

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

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

Решением данного вопроса может стать создании интегрированной инструментальной среды (ИИС), которая бы обеспечивала выполнение следующих требований:

• возможность интеграции разнородных приложений, удобным для пользователя образом;
• возможность обработки разнородной информации в специализированных приложениях;
• работа с содержимым проектного решения, его идейным наполнением;
• «контекстность» предоставляемой пользователю информации;
• отказ от конкретных форматов данных и их преобразований.
• Для успешного создания ИИС необходимо решить ряд задач:
• необходимо разработать новые принципы формирования информационных описаний проекта; Существующие сейчас способы представления проектной информации практически непригодны для их дальнейшего использования, поскольку скрывают логику выполнения отдельных шагов проектирования, сложно совмещаются с другими проектными решениями.
• необходимо найти как можно более универсальный способ управления различными инструментальными средами САПР без участия программиста;
• обеспечить возможность включения в проект объектов, построенных в различных средах САПР; Данная задача объясняется невозможностью всесторонней проработки проекта в рамках одной системы проектирования. А именно требования по всесторонней и максимально более тщательной проработке проекта диктует современный уровень задач проектирования.
• обеспечить параметризацию проектируемых объектов; Без возможности параметризации невозможно сейчас представить себе современную систему проектирования. И это неслучайно - она наиболее точно вписывается в рамки изложенных представлений о процессе автоматизации проектирования. Очень важно и полезно проследить изменение проекта при модификации или подборе ее параметров.
• обеспечить простое дополнение функциональных возможностей системы; Данную возможность включают в свои системы все разработчики современных САПР. Это объясняется невозможностью приспособить систему для решения всех задач проектирования. Расширить возможности системы позволяет включение новых модулей.
• разработать формат данных, позволяющий хранить созданные проектные решения в виде отдельных сущностей и связи между ними в пределах имеющихся проектов.

Архитектура ИИС.

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

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

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

Здесь существуют два общих подхода (возможных и в комбинации).

Первый - реализация отдельных модулей обеспечивающих взаимодействие отдельных целевых программ через себя.

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

Рис.2.1.Схема ИИС с Интерфейсными Модулями

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

Рис.2.2.Схема ИИС с Управляющим Модулем

Вторая схема хороша малым числом компонентов N+1, где N-число целевых программ, а также относительно лёгкой масштабируемостью (добавлением новых целевых программ в комплекс). Её недостаток - если между двумя отдельно взятыми целевыми программами идёт интенсивный обмен данными, то процесс разработки может сильно замедлиться из-за непродуктивного двойного преобразования.

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

Рис.2.3.Общая структура приложения

Структура приложения представлена на рис.2.3. , из которого видно, что приложение будет иметь модульную структуру и включать в себя следующие элементы:

Ядро - основа приложения, осуществляющее всю основную логику. В его "обязанности" будет входить: взаимодействие с базой данных; предоставление универсального интерфейса взаимодействия с Интерфейсными модулями, обеспечение гибкого интерфейса пользователя.

База данных - основное хранилище данных и мета-данных (данных о данных). Должна иметь структуру способную хранить проектные решения и информацию об их связях.

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

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

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

2.2Графический процессор в структуре ИИС

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

• Поддержка современных технологий трехмерного твердотельного моделирования.
• Поддержка современных технологий интеграции.
• Возможность параметризации проектируемых объектов.
• Возможность фиксации промежуточных и конечных результатов работы.

Предварительный обзор в первой главе показал, что Компас-3D в целом удовлетворяет этим требованиям. Проведем более глубокий анализ данного программного продукта.

2.2.1Компас-3D как Графический процессор ИИС.

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

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

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

Это, во-первых, предполагает наличие подсистем, расширяющих стандартные возможности программы, которые позволяют ускорить проектирование собственно объекта (агрегата, механизма, здания), а не отдельно взятой его детали или составляющей. Чаще всего такие подсистемы представляют собой подключаемые модули (библиотеки), функционирующие только в среде «родительского» графического редактора и позволяющие на основе его базовых функций быстро создавать и использовать различные стандартные элементы.

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

Очевидно, что качество любой программы для трехмерного инженерного моделирования определяют отнюдь не только базовые инструментальные средства. Зачастую как раз наоборот: чем больше возможностей для расширения списка доступных средств, тем выше система котируется предприятиями-заказчиками.[11]

Огромный перечень областей применения САПР - первая причина, по которой любая из современных CAD-систем должна быть максимально открытой и обязательно содержать инструменты для создания пакета пользовательских модулей (прикладных библиотек, приложений и т.д.). Второй причиной является ориентация на заказчика. Если, например, подавляющее большинство предприятий, использующих ту или иную систему, работают в машиностроении, а единицы - в области производства медицинского оборудования, то разработчики прикладных приложений вынуждены подстраиваться под первую категорию. Но для заказчиков КОМПАС никаких проблем не возникнет - они могут создать пользовательские модули самостоятельно.

Рассмотрим основные способы создания таких модулей:

• создание библиотеки фрагментов (эскизов) или моделей на основе базовых возможностей системы КОМПАС-3D;
• создание библиотеки шаблонов с помощью Менеджера шаблонов;
• использование специальной макросреды КОМПАС-Макро для подготовки пользовательского приложения;
• применение инструментальных средств КОМПАС-Мастер, то есть собственно написание (программирование) библиотек и приложений.

Создание библиотек фрагментов и моделей

Для создания библиотек этого типа не потребуется никаких специальных навыков, кроме умения работать в КОМПАС-График или в КОМПАС-3D. С помощью таких библиотек каждый проектировщик может систематизировать свой набор наиболее часто используемых элементов, чтобы облегчить доступ к ним при разработке новых чертежей или моделей.

Главное преимущество библиотек фрагментов - простота их создания и применения. Большим плюсом таких приложений является также то, что при появлении новых версий КОМПАС не нужно подгонять или изменять их структуру под только что выпущенный релиз. Достаточно загрузить старый файл библиотеки в Менеджер библиотек, и можете не сомневаться - всё будет работать.

Рис.2.4.Пример пользовательской библиотеки, содержащей модели шпонок, и ее применение

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

Создание библиотек шаблонов

Библиотека шаблонов - это прикладная библиотека, состоящая из базового параметризованного чертежа или трехмерной модели, таблицы переменных, набранной в соответствии с некоторыми правилами в табличном редакторе MS Excel, и схемы - документа КОМПАС-3D или рисунка, содержащего имена переменных. Библиотека представляет собой файл с расширением *.tlm, с помощью которого переменным параметризованного фрагмента или детали ставятся в соответствие значения, набранные в Excel-таблице. Для создания библиотек шаблонов предназначено специальное приложение под названием Менеджер шаблонов.

Разработку шаблона следует начинать с создания его прототипа (фрагмента или детали), пользуясь стандартными средствами КОМПАС-График или КОМПАС-3D. Затем необходимо параметризовать вычерченный фрагмент или эскизы модели и назначить внешними все переменные, которые вы планируете вводить (набирать) в таблице Excel. Следующим шагом является создание таблицы значений. Такая таблица формируется в редакторе Excel и включает названия внешних параметризованных переменных, флаги видимости колонок значений в Менеджере шаблонов, конкретные значения или их интервал для каждой переменной и др. Детально с правилами заполнения таблиц к шаблонам вы можете ознакомиться в файле-справке и примерах, поставляемых вместе с библиотекой шаблонов. Формирование еще одной составной части шаблона - схемы параметров - не вызовет особых затруднений. Схемой может быть любой графический файл системы КОМПАС-3D или файл-рисунок в формате *.bmp, *.gif или *.jpg.

Рис.2.5.Пример пользовательской библиотеки шаблонов для создания трехмерной модели гайки

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

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

Создание пользовательских библиотек с помощью КОМПАС-Макро

КОМПАС-Макро - это интегрированная в систему КОМПАС-3D среда разработки конструкторских приложений на основе языка программирования Python. Почему за основу выбран именно Python? Во-первых, Python распространяется бесплатно и, как следствие, не налагает никаких ограничений на использование и распространение написанных на нем программ. Во-вторых, сегодня Python - один из самых простых и понятных языков программирования, однако при всей своей простоте он мало в чем уступает таким «китам» объектно-ориентированного программирования, как C++ и Object Pascal (Delphi).

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

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

Для того, чтобы на практике убедиться в возможностях данной библиотеки, был проведен небольшой эксперимент: были «зафиксированы» действия пользователя, при выполнение ряда простейших задач - создание эскиза, создание прямоугольника в эскизе, задание размеров сторон прямоугольника, операция выдавливания. Для большей наглядности результаты были сравнены с результатами, которые были получены с помощью подобных средств фиксации действий пользователя (панель для создания макросов и файл протокола) системы SolidWorks. Листинг полученных скриптов приведён в Приложении 1.

Анализ скриптов, полученных в результате эксперимента привел к следующим выводам.

Для скриптов SolidWorks характерно:

• наличие «мусора» - строк скрипта, которые не принципиальны для сохранения сценария работы пользователя ( изменение вида, выделение объектов, изменение масштаба и т.д.)
• наличие автоматической генерации имен объектов - наличие «имен» у объектов позволяет обращаться напрямую к ним, минуя координаты. Тоесть позволяет в дальнейшем произвести параметризацию переменных.
• Для скрипта КОМПАС-3D характерно:
• отсутствие «мусора» - каждая строка скрипта необходима для корректного выполнения всего скрипта в целом. Присутствуют на первый взгляд «ненужные» строки, но они полностью описывают свойства создаваемых объектов и без этих строк объекты просто не будут созданы.
• отсутствие автоматической генерации имен объектов - мы имеем дело только с геометрическими координатами, мы лишены возможности напрямую обращаться к объектам. Произвести параметризацию переменных не представляется возможным
• Таким образом, можно сделать вывод о том, что хотя библиотека КОМПАС-Макро и пригодна для сохранения промежуточных результатов работы пользователя в системе КОМПАС-3D в виде макросов, для решения проблем рассматриваемых в данной работе она бесполезна. Это объясняется, прежде всего, тем, что без параметризации, сохраненные промежуточные результаты работы не представляют особой ценности.
• КОМПАС-Мастер
• КОМПАС-Мастер - это очень мощные инструментальные средства разработки приложений (библиотек) неограниченной сложности, функционирующих в среде КОМПАС-3D. С помощью КОМПАС-Мастер прикладной программист получает доступ ко всем без исключения функциям системы. То есть абсолютно всё, что пользователь может делать вручную, - будь то создание или редактирование графического документа, открытие и закрытие файлов, работа со спецификациями, создание таблиц, оформление чертежей, сохранение файлов в различных форматах, вставка рисунков и т.д. и т.п. - все это может быть автоматизировано с использованием КОМПАС-Мастер.
• Доступ к внутренним функциям КОМПАС-График и КОМПАС-3D обеспечивается двумя путями:
• через экспортные функции, оформленные в виде dll-модулей, которые разработчик подключает к своей программе, - при создании плоских чертежей; через использование СОМ-объектов - при программном формировании твердотельных моделей;
• с помощью технологии Automation (Автоматизации), реализованной через API (Application Programming Interface - программный интерфейс приложения) системы КОМПАС. Управление и взаимодействие с системой при этом оформлено через интерфейсы IDispatch.

Рис.2.6.Создание прикладных библиотек с помощью API

Использование интерфейсов IDispatch возможно в любой из наиболее распространенных сегодня сред программирования (Visual C++, Delphi, C++Builder, Visual Basic). Интеграция с такими мощными программными пакетами позволяет, помимо применения графического инструментария КОМПАС, использовать в создаваемых модулях все преимущества современного объектно-ориентированного программирования.

На последнем рисунке изображены трехмерные сборки четырех различных типов муфт (зубчатой, упругой втулочно-пальцевой, торообразной с резиновой оболочкой и продольно-свертной), в которых на первый взгляд нет ничего необычного. Ничего, за исключением того, что все эти муфты полностью сгенерированы программно - при помощи конструкторской библиотеки, разработанной в среде КОМПАС-Мастер. Их создание заключалось только в выборе пользователем диаметра соединяемых валов и нажатии кнопки «Строить». Все остальные операции спрятаны внутри программы.

Рис.2.7.Муфты, сгенерированные с помощью приложения, разработанного в среде КОМПАС-Мастер

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

Зато, преодолев все эти трудности, можно получить удобное и гибкое приложение, обладающее функциональностью и интерфейсом, которые полностью удовлетворяют вашим требованиям. Программу можно заставить «думать» - самостоятельно выбирать, анализировать и обрабатывать необходимые данные, производить определенные действия в зависимости от прочитанных значений, делать сложные расчеты и выводы по их результатам и пр. И всё это для того, чтобы максимально облегчить работу инженера, избавить его от выполнения рутинных операций.[12]

Таким образом, если подвести итог всему вышесказанному, можно сделать вывод о том, что система трехмерного твердотельного проектирования КОМПАС-3D действительно соответствует требованиям, предъявляемым к Графическому процессору интегрированной инструментальной среды:

• Поддерживается большинство современных технологий трехмерного моделирования.
• КОМПАС-Мастер предоставляет все необходимые инструменты для организации связи с внешними приложениями.
• Параметризация обеспечивается через присвоение ключевым переменным псевдонимов в панели «Переменные».
• Сохранение конечных результатов работы пользователя осуществляется в файлах чертежа, модели, сборки. Лишь организовать сохранение промежуточных результатов в виде параметризованных макросов не представляется возможным.

2.2.2Схема взаимодействия Графического процессора с компонентами интегрированной инструментальной среды

Такие компоненты ИИС как Ядро, Интерфейс пользователя, Интерфейс взаимодействия с БД, БД являются принципиально важными элементами, без которых невозможно решение проблемы комплексной автоматизации проектирования. Но нельзя не отметить и тот факт, что все вышеперечисленные компоненты выполняют лишь сервисные функции, в своей совокупности облегчая и ускоряя процессор проектирования. В то время как основной объём работ выполняется в Графическом и Математическом процессорах. Следовательно, можно сделать вывод о том, что построение полноценной ИИС без организации продуктивного обмена данными между этими двумя компонентами невозможно.

Поэтому, для того, чтобы исследовать механизмы построения ИИС на базе Компас-3D и однозначно ответить на вопрос, подходит ли данная система трехмерного твердотельного моделирования на роль Графического процессора, необходимо и достаточно уделить основное внимание цепочке, приведенной на рис.2.8.

Рис.2.8.Цепочка взаимодействия Графического и Математического

процессоров

Именно эта цепочка во многом определяет возможности ИИС и логику её работы. Без полноценного обмена данными между Графическим и Математическим процессором невозможно будет организовать параметризацию, связывание, хранение в БД переменных на уровне всей ИИС.

Как было показано в первой главе, на роль Математического процессора вполне подходит хорошо зарекомендовавший себя MathCAD. Данный выбор обусловлен, прежде всего, двумя особенностями продукта:

• Поддержка современных механизмов интеграции (API-интефейс, XML-рабочий файл).
• Необходимый уровень абстракции (иными словами, удобный интерфейс и логика работы: мы просто набираем формулы и получаем результат, подобно расчёту на бумаге; это выгодно отличает MathCAD от других математических пакетов, присутствующих на рынке, со сложным синтаксисом команд)

Благодаря наличию в MathCAD текстового редактора, от отдельного Текстового процессора в структуре ИИС можно на время отказаться, так как это не является принципиально важным для организации её работы.

Таким образом, окончательно структура приложения будет выглядеть, как показано ниже на рис.2.9.

Рис.2.9.Структура приложения

2.2.3Схемы взаимодействия КОМПАС-3D и MathCAD на основе доступных механизмов интеграции.

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

Для MathCAD:

• API-интерфейс.
• Технология составных документов.
• Экспорт/импорт таблицы входных/выходных переменных в Excel.
• Синтаксический анализ выходного файла.
• Для КОМПАС-3D:
• API-интерфейс.
• Экспорт/импорт таблицы внешних переменных в Excel.
• Синтаксический анализ скрипта макроса.

Но наиболее подходящими для решения задач, озвученных в данной работе, можно считать API-интерфейс, а так же синтаксический анализ выходного файла для MathCAD. На основе выбранных механизмов интеграции можно составить две различных схемы взаимодействия MathCAD и КОМПАС-3D. Данные схемы приведены ниже на рис.2.10 и рис.2.11.

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

Использование синтаксического анализатора в некоторых случаях позволяет пользоваться большей свободой действий.

Обе схемы будут апробированы в ходе программной реализации.

Рис. 2.10. Схема взаимодействия MathCAD и КОМПАС-3D на основе API-интерфейса

Рис. 2.11. Схема взаимодействия MathCAD и КОМПАС-3D на основе API-интерфейса и Синтаксического анализатора.

2.3Модель данных и иерархическая структура функций ИИС

В ходе анализа задачи были выделены несколько сущностей, реализация и использование которых дали бы возможность организовать полноценный обмен данными между Графическим и Математическим процессором.

Проект (Пр) - наибольшая абстракция, которая хранит в себе все действия пользователя и всю сопутствующую информацию.

Проектная операция (ПО) - некоторый набор действий, выполняемых пользователем и выделяемых им в отдельную смысловую единицу, являющиеся выполнением некоторых действий, которые лишь в совокупности обладают смыслом для пользователя.

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

Связь (С) - cвязь между переменными операций (П).

Таким образом, модель данных определяется следующими множествами объектов:

1) Множество проектов, Пр

{Прi <Project_ID, Project_Name, Project_Description> }_ID - уникальное число-идентификатор проекта;

Project_Name - имя проекта;

Project_Description - подробное описание содержания проекта.

2) Множество проектных операций, ПО

{ПОi <Operation_ID, Operation_Name, Project_ID, Operation_Type, Operation_Description > }_ID - уникальное число-идентификатор проектной операции;

Operation_Name - имя проектной операции,;

Project_ID - идентификатор проекта, которому принадлежит операция;

Operation_Type - тип проектной операции;

Operation_Description - подробное описание проектной операции.

3) Множество переменных операциям, П

{Пi <Variable_ID, Variable_ID, Operation_ID, Variable_Type, Variable_Value, Variable_Description >}_ID - уникальное число-идентификатор переменной;

Variable_Name - имя переменной, отображающее смысловое наполнение;

Operation_ID - идентификатор операции, которой принадлежит переменная;

Variable_Type - тип переменной;

Variable_Value - значение переменной;

Variable_Description - описание переменной;

) Множество связей между переменными операций С

{Сi<VariableConnection_ID, Variable_ID, VariableConnected_ID >}_ID - уникальное число-идентификатор связи;

Variable_ID - идентификатор переменной;

VariableConnected_ID - идентификатор связанной переменной;

Опираясь на модель данных, можно сформировать иерархическую структуру функций ИИС:

·Создание проекта

oВызов диалогового окна с вводомназвания проекта

oСоздание проектной операции. Это Функция вызывается каждый раз, когда создаётся новая проектная операция.

oСвязывания проектных операций

·Создание проектной операции

oВыбор типа проектной операции

§Математическая (MathCAD)

§Графическая (КОМПАС-3D)

oВызов процессора (Математического или Графического).

oСоздание Расчёта (Геометрической модели) в процессоре.

oПараметризация Расчёта (Геометрической модели).

oСохранения Расчёта (Геометрической модели).

oАвтоматическое создание переменных проектной операции и связывание их с параметрами Расчёта(Геометрической модели).

2.4Выводы

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

В ходе исследования возможностей КОМПАС-3D был сделан вывод: КОМПАС-3D вполне удовлетворяет требованиям, предъявляемым к Графическому процессору ИИС. В ходе анализа возможностей интеграции КОМПАС-3D и MathCad пришли к выводу, что существуют как минимум две схемы для их взаимодействия.

Следующие шаги в решении задачи:

1.Разработка Интерфейсного модуля для КОМПАС-3D;

2.Разработка Интерфейсного модуля для MathCAD;

.Разработка Модуля взаимодействия КОМПАС-3D и MathCAD;

.Разработка структуры базы данных;

.Создание БД на основе выбранной СУБД или драйверов БД;

.Разработка пользовательского интерфейса для Управляющего модуля ИИС

3.Программная реализация

3.1Выбор средств разработки приложений

Рассматривая современные средства разработки приложений, можно заметить, что их развитие подчиняется определённым закономерностям и тенденциям.

Первой из таких тенденций является использование в программировании объектно-ориентированного подхода, позволившее осуществлять повторное использование кода с большей эффективностью, нежели при применении так называемого модульного программирования. Зачатки объектного подхода появились во многих популярных в 80-х годах средствах разработки, таких, например, как Clipper. Однако расцвет объектно-ориентированного программирования начался с появления языка C++.

Второй немаловажной тенденцией развития средств разработки являлось создание высокопроизводительных компиляторов и стремление использовать скомпилированный код. Известно, что последний обладает существенно более высокой производительностью, чем код интерпретируемый. Отметим, что наличие исполняемого файла как результата создания приложения не гарантирует, что созданный код не является интерпретируемым (типичные примеры средств разработки, создающих исполняемый файл с интерпретируемым кодом - Centura SQLWindows, Visual FoxPro, Clipper, Visual Basic, Developer-2000).

Третьей тенденцией развития инструментальных средств являлось создание визуальных средств проектирования пользовательских интерфейсов, что позволило ускорить работу над проектами, облегчить повторное использование кода и в определенной степени привлечь к созданию приложений начинающих программистов. Наиболее ярким примером такого средства явилось появление в середине 90-х годов Visual Basic, имеющего в своем составе элементы VBX, из которых можно было строить интерфейс приложения, просто размещая их на форме, а также различных средств редактирования ресурсов типа Borland Resource Workshop. Отметим, однако, что в случае Visual Basic пользователь вынужден был довольствоваться готовыми VBX элементами либо создавать их на языке С с помощью других средств разработки.

И наконец, еще одним немаловажным фактором развития инструментальных средств явилась необходимость масштабируемой поддержки баз данных, так как, во-первых, именно информационные системы стали наиболее часто встречающимся типом разрабатываемых приложений и, во-вторых, именно в конце 90-х годов начался массовый переход от настольных СУБД к архитектуре клиент/сервер. Отметим, однако, что далеко не все средства разработки одинаково хорошо поддерживают все СУБД - нередко имеется явная ориентация на поддержку SQL-сервера того же производителя, что и производитель средства разработки (типичный пример - средства разработки Oracle).C# представляет собой следствие влияния всех этих тенденций, так как сочетает в себе удобства визуальной среды разработки, объектно-ориентированный подход, разнообразные возможности повторного использования кода, открытую архитектуру, а также масштабируемый доступ к данным, хранящимся в различных СУБД, как настольных, так и серверных.

Visual C# - объектно-ориентированный <#"justify">Под базой данных понимают хранилище структурированных данных, при этом данные должны быть непротиворечивы, минимально избыточны и целостны. Всякая БД должна представлять собой систему данных о предметной области.

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

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

При разработке структур реляционных БД необходимо учитывать ряд существенных моментов.

В каждой таблице БД может существовать первичный ключ. Под первичным ключом понимают поле или набор полей, однозначно идентифицирующий запись. Значение первичного ключа в таблице БД должно быть уникальным, то есть в таблице не должно существовать двух или более записей с одинаковым значением первичного ключа.

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

Существует три разновидности связей между таблицами базы данных: "один-ко-многим", "один-к-одному", "многие-ко-многим".

Отношение "один-ко-многим" имеет место, когда одной записи родительской таблицы может соответствовать несколько записей в дочерней таблице.

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

Отношение "один-к-одному" имеет место, когда одной записи в родительской таблице соответствует одна запись в дочерней таблице.

Отношение "многие-ко-многим" имеет место, когда:

а) записи в родительской таблице может соответствовать больше одной записи в дочерней таблице;

б) записи в дочерней таблице может соответствовать больше одной записи в родительской таблице .

Многие СУБД не поддерживают связи "многие-ко-многим" на уровне индексов и ссылочной целостности, хотя и позволяют реализовывать ее в таблицах неявным образом.

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

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

Под операционными таблицами понимаются таблицы БД, в которых происходит устойчивое во времени непрерывное или периодическое обновление или добавление информации. Операционные таблицы находятся, как правило, в подчиненном отношении со справочными таблицами.

Как уже говорилось, одним из шагов реализации является разработка структуры БД. Собственно, предложенные в модели данных множества элементарно представляются в виде ТБД, а элементы (кортежи) - есть записи ТБД. Таким образом, для хранения каждого из множества объектом заведем отдельную ТБД. В результате получим следующие таблицы.

Projects (Проекты)Project_IDProject_NameProject_DescriptionИдентификатор ПроектаИмя ПроектаКомментарий ПроектаOperations (Операции)Operation_IDOperation_NameProject_IDOperation_TypeOperation_DescriptionИдентификатор ОперацииИмя ОперацииИдентификатор ПроектаТип ОперацииКомментарий Операции

OperationType (Типы операций)OperationType_IDOperationType_NameOperationType_DescriptionOperationType_NumberИдентификатор Типа операцииИмя Типа операцииКомментарий Типа операцииНомер Типа операции

Variables (Переменные)Variable_IDVariable_ NameOperation_IDVariable_TypeVariable_ValueVariable_ DescriptionИдентификатор ПеременнойИмя ПеременнойИдентифик. ПеременнойТип ПеременнойЗначение ПеременнойКомментарий Переменной

VariableType (Типы переменных)VariableType_IDVariableType_NameVariableType_DescriptionVariableType_NumberИдентификатор Типа перемен.Имя Типа переменнойКомментарий Типа переменнойНомер Типа переменной

VariableConnections (Связи переменных)VariableConnection_IDVariable_IDVariableConnected_IDИдентификатор Связи переменныхИдентификатор ПеременнойИдентификатор Связанной переменной

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

Рис.3.1.Структура Базы Данных

Данная структура БД позволяет описывать множество проектов, проектных операций, переменных и связей между ними.

Исходя из модели данных, имеем множество проектов, каждый из которых имеет свои проектные операции. Каждая проектная операция имеет свои переменные, и характеризуется идентификатором типа операции, из множества типов операций, и т.д.

3.3Разработка Интерфейсных модулей

3.3.1Разработка Интерфейсного модуля для КОМПАС-3D

Ознакомимся с API-интерфейсом системы КОМПАС-3D, для того, чтобы лучше понять к каким внутренним возможностям можно получить доступ. Так же рассмотрим некоторые особенности параметризации системы КОМПАС-3D.

Любая САПР твёрдотельного моделирования работает в интерактивном режиме. Поэтому для исследования подходит язык программирования С# совместно с библиотеками КОМПАС-МАСТЕР, которые предоставляют доступ к классам и функциям графического ядра.

Рис.3.2.Вид панели «Переменные» Компас-3D

Компас-3D поддерживает автоматическую генерацию имен объектов - каждый вновь созданный объект автоматически получает уникальное имя. Но эти имена предназначены лишь для внутреннего использования. Невозможно напрямую обратиться к объекту с уникальным именем из внешнего приложения (возможно только создание итератора и последовательного перехода по объектам определенного типа). Это является следствием особенностей работы графического ядра и налагает некоторые ограничения: доступ из внешних приложений возможен только к тем переменным, которые были заранее созданы пользователем.

Создание переменных, к которым разрешен доступ из внешних приложений через API-интерфейс, происходит с помощью панели «Переменные» изображенной на рис.3.2.

Рис.3.3.Назначение свойства «Внешняя» для переменной в панели «Переменные» КОМПАС-3D

Рис.3.4.Пользовательский интерфейс Интерфейсного модуля ExVarCompass3D

Для того, что бы переменная стала доступна для внешних приложений необходимо указать в её свойствах «Внешняя» (см. рис.3.3.), цвет ячейки изменится на синий, сигнализируя нам об изменениях.

Теперь воспользуемся небольшим программным модулем ExVarCompass3D, выполняющего роль Интерфейсного модуля для КОМПАС-3D, что бы на практике убедиться в возможности обмена данными с внешними приложениями (Листинги программного кода для этого и остальных модулей приведены в Приложении 4). Пользовательский интерфейс ExVarCompass3D представлен на рис.3.4.

Как видно из вышеупомянутого рисунка данный Интерфейсный модуль позволяет запускать Компас-3D, открывать в нём файл сборки, считывать внешние переменные в таблицу (имя, значение, комментарий), изменять значения переменных и перестраивать сборку согласно новым данным. Ниже на рис. 3.5. и рис.3.6. показаны этапы работы.

Рис.3.5.Считывание внешних переменных сборки КОМПАС-3D с помощью Интерфейсного модуля ExVarCompass3D

Рис.3.6.Ввод значений и запись внешних переменных, перестроение сборки КОМПАС-3D с помощью Интерфейсного модуля ExVarCompass3D

Не имеет смысла приводить полный код программы, но стоит указать основные объекты и методы, которые позволяют работать с переменными, созданными в панели «Переменные» Компас-3D:

// Работа с массивом внешних переменныхvarCol = (ksVariableCollection)part.VariableCollection();(int j = 0; j < varCol.GetCount(); j++)

{

// Считывание переменных с записью в таблицу= (ksVariable)varCol.GetByIndex(j);.TableCompassEV.Rows.Add(var.name, var.value, var.note);

// Запись переменных из таблицы в сборку.value = this.TableCompassEV.Rows[i].Cells[1].Value.ToString();

}

//Перестроение сборки.RebuildModel();

- коллекция, содержащая массив внешних переменных, созданных в Компас-3D.

var - конкретная внешняя переменная, содержащая необходимые нам данные: имя, значение, комментарий.() - метод, позволяющий перестраивать сборку.

По результатам работы в ExVarCompass3D можно сделать вывод о том, что к необходимым нам функциям Компас-3D можно получить доступ через API-интерфейс. Это, в свою очередь, на практике подтверждает, что Компас-3D вполне удовлетворяет требованиям, предъявляемым к графическому процессору в рамках разрабатываемой ИИС.

3.3.2Разработка Интерфейсного модуля для MathCAD

Хотя в Компас-3D присутствует некоторая математическая поддержка, которая реализована в панели «Переменные», где можно задать различные выражения с участием переменных (см. рис.3.7.), её возможностей явно не хватает при необходимости произвести более сложные расчёты.

Рис.3.7.Математическая поддержка, реализованная в панели «Переменные» КОМПАС-3D: значение H3 равно значению H1, значение Step вычисляеться согласно выражению (W1+W2)*2

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

После анализа функций математического ядра, к которым можно получить доступ через API-интерфейс, было установлено, что для работы с переменными доступны лишь два метода:

objMC.SetValue(Name As String, Value As Variant) - метод используется для того, чтобы задать значение входной переменной с известным именем.

VT_DISPATCH = objMC.GetValue(Name As String) - метод используется для того, чтобы считать значение выходной переменной с известным именем.

Причем для использования этих методов, расчёт в MathCadе должен быть оформлен определенным образом (см. рис.3.8.)

Рис.3.8.Оформление расчёта в MathCAD для успешного использования методов SetValue и GetValue.

Для входных переменных необходимо зарезервировать имена, начинающиеся на in с номерами от 0 до 9 (именно это количество входных переменных инициализируется в момент создания, им изначально присваивается значение 0; использование входной переменной in10 уже не допускается, так как она не инициализируется по умолчанию). Эти переменные должны располагаться справа от знака равенства в начале расчета и встречаться лишь один раз.

Для выходных переменных необходимо зарезервировать имена, начинающиеся на out с произвольными номерами. Эти переменные должны располагаться слева от знака равенства в конце расчета и встречаться также лишь один раз.

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

Таким образом, можно сделать вывод, хотя и с некоторыми оговорками, что в MathCadе имеются инструменты для доступа к входным и выходным переменным через API-интерфейс.

Для того, чтобы рассмотреть альтернативный вариант интеграции - возможность использования синтаксического анализатора выходного файла MathCAD текстового формата (XML), проанализируем структуру файла для рабочего листа, изображенного на рис.3.9.:

Рис.3.9.Пример простейшего расчёта в рабочем листе MathCAD.

Ниже приведена немного упрощенная структура этого файла:

<regions>

<region region-id="1">

<ml:define>

<ml:id >x</ml:id>

<ml:real>1</ml:real>

</ml:define>

</region>

<region region-id="3">

<ml:define>

<ml:id >y</ml:id>

<ml:real>1</ml:real>

</ml:define>

</region>

<region region-id="7">

<ml:define>

<ml:id >z</ml:id>

<ml:apply>

<ml:plus/>

<ml:id>y</ml:id>

<ml:id>x</ml:id>

</ml:apply>

</ml:define>

</region>

<region region-id="8">

<ml:eval>

<ml:id >z</ml:id>

<result>

<ml:real>2</ml:real>

</result>

</ml:eval>

</region>

<region region-id="29">

<ml:eval>

<ml:id>x</ml:id>

<result>

<ml:real>1</ml:real>

</result>

</ml:eval>

</region>

<region region-id="27">

<ml:eval>

<ml:id >y</ml:id>

<result>

<ml:real>1</ml:real>

</result>

</ml:eval>

</region>

</regions>

После сравнения рабочего листа и структуры файла можно сделать следующие выводы:

Тег <regions> содержит в себе перечень всех регионов рабочего листа.

Тег <region region-id="27"> содержит описание нумерованного региона.

Тег <ml:define> заключает в себе операцию присвоения (:=).

Тег <ml:eval> заключает в себе операцию вычисления (=).

И так далее: понять значение каждого тега не составляет особого труда.

После более подробного анализа можно составить словарь используемого в данном файле «наречия» языка XML и создать синтаксический анализатор для обработки данного файла. Это, в свою очередь, позволит организовать обмен переменными с внешним приложением. Причем мы сможем обращаться к переменным с любым именем - даже если это имя будет не уникально и будет встречаться несколько раз за время расчёта, мы все равно сможем отличить переменные друг от друга по уникальному номеру региона. Применение синтаксического анализатора так же снимает требование на специальное оформление рабочего файла расчёта и ограничение на количество переменных.

Для того, чтобы на практике убедиться в возможности обмена данными с внешними приложениями и сравнить механизмы интеграции (API-интерфейс и XML-анализатора) воспользуемся небольшими программными модулями VarMathCAD_API и VarMathCAD_XML, которые будут выполнять роль Интерфейсного модуля для MAthCAD.

Пользовательский интерфейс VarMathCAD_API и VarMathCAD_XML представлен на рис.3.10. и рис.3.11.

Рис.3.10.Пользовательский интерфейс Интерфейсного модуля VarMathCAD_API

Рис.3.11.Пользовательский интерфейс Интерфейсного модуля VarMathCAD_XML

Этапы работы с VarMathCAD_API:

Рис.3.12.Открытие файла расчета с помощью Интерфейсного модуля VarMathCAD_API.

Как видно из вышеупомянутых рисунков Интерфейсные модули позволяют запускать MathCAD, открывать в нём файл расчёта, считывать входные и выходные переменные в таблицы (имя, значение, тип), изменять значения переменных и пересчитывать расчёт согласно новым данным. Ниже на рис. 3.12., 3.13., 3.14., 3.15., 3.16. показаны этапы работы с данными модулями.

Рис.3.13.Присваивание значений входным переменным расчета с помощью Интерфейсного модуля VarMathCAD_API

Рис.3.14.Пересчет расчёта и считывание значений выходных переменных расчета с помощью Интерфейсного модуля VarMathCAD_API.

Этапы работы с VarMathCAD_XML:

Рис.3.15.Открытие файла расчета, считывание всех переменных с помощью Интерфейсного модуля VarMathCAD_XML.

Рис.3.16.Изменение значений входных переменных расчета, пересчет расчета, считывание значений выходных переменных расчета с помощью Интерфейсного модуля VarMathCAD_XML

Результаты работы с Интерфейсным модулем VarMathCAD_API говорят о том, что MathCAD удовлетворяет требованиям, предъявляемым к математическому процессору разрабатываемой ИИС. Кроме того можно сделать вывод, что через API-интерфейс можно организовать обмен переменными между MathCAD и КОМПАС-3D.

Но данный подход представляется малоэффективным. Это, прежде всего, связано с логикой работы MathCad и скудостью функций математического ядра, которые доступны через API-интерфейс.

Особенности работы MathCAD через API-интерфейс:

• Специальные жесткие требования к оформлению расчёта, которые усложняют работу и снижают эргономичность.
• Из внешних приложений возможна работа только с обезличенными переменными с префиксами in и out, которые невозможно автоматически , без участия пользователя, сопоставить с реальными именами переменных в расчёте.
• Нельзя задать значения по умолчанию для входных переменных in в самом теле расчёта, иначе изменение значений этих переменных из внешних приложений станет невозможным.
• В момент создания инициализируются лишь 10 входных переменных in0-in9 (по умолчанию им присваивается значение ноль). Большее количество входных переменных, не используя матричной формы представления, задействовать невозможно.
• Возможности, не реализованные в функциях математического ядра MathCad, которые были бы полезны при доступе через API-интерфейс :
• Возможность получить список имен и значений всех переменных, участвующих в операциях присвоения и вычисления ( := и = )
• Возможность обращаться к переменной по номеру графического региона (или по уникальному номеру), что позволит различать переменные с одинаковым именем, встречающиеся несколько раз по ходу расчёта

Обойти указанные особенности логики работы MathCAD и реализовать недостающие возможности математического ядра можно, с помощью синтаксического анализатора, который способен обрабатывать мета-язык рабочего файла MathCAD. Данные выводы были подтверждены при работе с Интерфейсным модулем VarMathCAD_XML. Решение этой задачи стало возможным благодаря введению, наряду с бинарным форматом файла, текстового формата, начиная с 12 версии MathCadа.

3.3.3Разработка механизма связывания переменных

Выше были показаны Интерфейсные модули как для КОМПАС-3D, так и для MathCAD. В процессе их разработки и апробации были экспереминтально проверены доступные механизмы интеграции. Но получить инструменты для обмена переменными это только полдела. Следующей задачей, которую предстоит решить, является связывание переменных между собой. Для решения этой проблемы необходимо разработать механизм связывания переменных.

Подобный механизм был реализован на базе Интерфейсных модулей ExVarCompass3D и VarMathCAD_API, которые работают через API-интерфейс. На их основе был создан программный модуль IntegratorKM_Lite. Пользовательский интерфейс модуля и этапы работы приведены на рис.3.17.,3.18.,3.19.

Как видно из нижеприведенных рисунков в данном программном модуле были объединены возможности ExVarCompass3D и VarMathCAD_API, а так же добавлены инструменты для связывания переменных MathCAD и КОМПАС-3D.

Связывание переменных производиться с помощью двух рядов выпадающих списков, которые содержат в себе список переменных MathCAD - это довольно простой и удобный способ. Переменной КОМПАС-3D автоматически присваивается значение выбранной из списка переменной MathCAD; связи заноситься в базу данных.

Рис.3.17.Ввод значений входных переменных MathCAD с помощью программного модуля IntegratorKM_Lite.

Рис.3.18.Пересчёт расчёта MathCAD по нажатии кнопки «Применить» и считывание выходных переменных MathCAD с помощью программного модуля IntegratorKM_Lite.

Рис.3.19.Связывание переменных MathCAD и КОМПАС-3D c помощью программного модуля IntegratorKM_Lite.

Как следствие ранее перечисленных особенностей работы MathCAD через API-интерфейс, в IntegratorKM_Lite для того, чтобы правильно задать значение входных переменных и определить связи между переменными MathCAD и КОМПАС-3D, в файле расчёта MathCAD приходиться создавать небольшую памятку как на рис.3.20.

Рис.3.20.Памятка в теле расчёта MathCAD

Это, в свою очередь, значительно снижает преимущества автоматизированного подхода. Поэтому было принято окончательное решение сохранить реализованный в IntegratorKM_Lite механизм связывания переменных, но отказаться от использования API-интерфейса для связи с MathCAD в пользу Синтаксического анализатора.

Таким образом, в основу ИИС будут положены Интерфейсный модуль для КОМПАС-3D ExVarCompass3D, Интерфейсный модуль для MathCAD VarMathCAD_XML, Механизм связывания переменных из модуля IntegratorKM_Lite.

Далее будет разработан графический интерфейс пользователя интегрированной инструментальной среды.

3.4Разработка графического интерфейса пользователя ИИС.

Общий вид графического интерфейса пользователя представлен на рис.3.21.

Рис.3.21.Общий вид графического интерфейса пользователя ИИС

На рабочем поле присутствуют четыре вкладки «Проекты», «Операции», «Расчёт», «Переменные» (действия доступные на этих вкладках дублируются в верхнем меню).

Менеджер проектов (Рис.3.21.) содержит список всех созданных проектов, проект содержит список документов проекта, в проект можно добавить любой документ, содержащийся в БД ИИС, и связать его с проектной операцией.

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

Рис.3.22.Содержимое вкладки «Операции»

ИИС работает с двумя типами документов:

• Документ, хранящий параметризованную модель или сборку КОМПАС-3D. Он представляет собой инструмент параметрического 3D моделирования (Графический документ). Работа с данным типом документа производиться на вкладке «Модель» (рис.3.23).

Рис.3.23.Содержимое вкладки «Модель». Кнопки позволяют работать с документами КОМПАС-3D

• Документ, хранящий расчёт MathCAD. Он представляет собой инструмент для выполнения символьных вычислений (Математический документ). Работа с данным типом документа производиться на вкладке «Расчёт» (рис.3.23).

Рис.3.24.Содержимое вкладки «Расчёт». Кнопки позволяют работать с документами MathCad

При открытии на вкладках «Модель» и «Расчёт» уже созданных документов соответствующих типов автоматически происходит считывание переменных проектных операций в таблицы (рис.3.25).

Рис.3.25.Считывание переменных проектных операций в таблицы

Связывание переменных происходит с помощью выпадающих списков как показано на рис.3.25. После выбора переменной в выпадающем списке происходит автоматическая передача её значения. Передача данных возможна как в прямом, так и в обратном направлении.

Рис.3.26.Связывание переменных проектных операций с помощью выпадающего списка

3.5Выводы

Результатом разработки системы явилось:

• Разработана структура БД, позволяющая хранить информацию о проектной деятельности.
• Разработаны три интерфейсных модуля, которые позволили экспериментально опробовать и выбрать подходящие механизмы интеграции;
• Разработан графический интерфейс пользователя, позволяющий в удобной форме производить обмен данными между КОМПАС-3D и MathCAD;
• К направлениям дальнейшей работы можно отнести следующее:
• Разработка инструментов, которые позволили бы создавать параметризированные макросы или параметризировать создаваемые с помощью КОМПАС-Макро (для сохранения промежуточных результатов работы в КОМПАС-3D) ;
• Доработка интерфейса пользователя для более удобного процесса проектирования (внедрение как ActiveX-объектов КОМПАС-3D и MathCAD непосредственно в рабочую область, и т.п.);

4.Апробация программного решения

Ниже приведен типовой пошаговый сценарий работы пользователя:

1.Создание нового проекта в Менеджере проектов с помощью кнопки «Создать» (автоматически присваивается номер, вводиться название и описание проекта)

2.Создаются новые проектные операции в Менеджере проектных операций с помощью кнопки «Создать» (автоматически присваивается номер и вводиться дата, выбирается тип операции, вводиться название и описание операции)

.Создаётся новый математический документ с помощью кнопки «Создать» на вкладке «Расчёт». Запускается MathCAD, выполняется расчёт. После сохранения расчёта переменные и их значения автоматически заносятся в таблицу «Переменные MathCAD». С этой таблицей можно работать далее, изменяя значение присвоенных переменных и считывая значение вычисленных переменных. Пересчёт расчёта производится с помощью кнопки «Применить» на вкладке «Расчёт».

.Создаётся новый графический документ с помощью кнопки «Создать» на вкладке «Модель». Запускается КОМПАС-3D, строится модель (деталь, сборка). После сохранения модели внешние переменные и их значения автоматически заносятся в таблицу «Переменные КОМПАС-3D».

.Выполняется операция связывания переменных в таблице «Переменные КОМПАС-3D» - значения переменных MathCAD присваиваются внешним переменным КОМПАС-3D с помощью выпадающих списков (столбец таблицы «Перем. MathCAD»).

.Выполняется перестроение модели по новым данным с помощью кнопки «Применить» на вкладке «Модель».

4.1Пример проектирования ребристого радиатора в ИИС

4.2Пример проектирования шпоночной протяжки в ИИС

4.3Выводы

В данной главе описан сценарий работы пользователя в программном модуле (в котором реализована значительная часть функций Управляющего модуля ИИС) «Kompas-MathCad Integrator» и проведена апробация данного модуля на двух примерах: Ребристый односторонний радиатор и Шпоночная протяжка (материалы для расчётов приведены в Приложении 2 и 3).

Проведенный программный эксперимент показал возможность создания интегрированной инструментальной среды на базе КОМПАС-3D.

К достоинствам разработанного модуля, можно отнести следующее:

• Простота и понятность интерфейса;
• Автоматическое считывание переменных и возможность контекстного связывания переменных в момент их создания;
• Возможность использования ранее накопленных проектных решений целиком или частично;
• К направлениям для дальнейшей работы можно отнести следующее:
• Добавление возможностей параметризации макросов, созданных с помощью библиотеки КОМПАС-Макро или других инструментов (для организации сохранения промежуточных результатов работы);
• Оптимизация взаимодействия с пользователем;
• Расширение набора служебных модулей для взаимодействия с другими приложениями (в частности в данной работе не был разработан модуль для интеграции текстового процессора).

Заключение

В ходе проделанной работы были рассмотрены существующие методы автоматизации проектной деятельности, и указаны их недостатки. Как метод их устранения, был рассмотрен способ создания интегрированной инструментальной среды на базе КОМПАС-3D, позволяющей организовать обмен данными между приложениями и сохранение результатов проектной деятельности в БД.

Были исследованы архитектура и функционал интегрированной инструментальной среды, механизмы её построения. Были сформулированы требования, предъявляемые к графическому процессору в рамках ИИС. Исследовались инструменты для интеграции КОМПАС-3D и расширения его возможностей. Рассматривались варианты взаимодействия КОМПАС-3D с MathCAD.

Практическая часть работы была реализована в виде программного компонента «Kompas-MathCad Integrator», который, являясь связующим звеном, интегрирует возможности графического процессор КОМПАС-3D, математического процессора MathCAD и СУБД MS Access. На практике было доказано, что КОМПАС-3D соответствует требованиям, предъявляемым к графическому процессору. Так же была повышена эффективность математической поддержки в системе КОМПАС-3D.

Завершающим этапом работы стал эксперимент, в ходе которого была доказана работоспособность созданной программы.

Литература

1.Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем, статья - #"justify">Приложение 1

Листинги скриптов Компас-3D и SolidWorks

Скрипт SolidWorks 2006 извлеченный из файла протокола swxJRNL.swj

Dim swApp As ObjectPart As ObjectSelMgr As Objectboolstatus As Booleanlongstatus As Long, longwarnings As LongFeature As Objectmain()swApp = Application.SldWorks.ActiveDoc.ActiveView.FrameLeft = 0.ActiveDoc.ActiveView.FrameTop = 0.ActiveDoc.ActiveView.FrameState = 1.ActiveDoc.ActiveView.FrameState = 1Part = swApp.NewDocument ("C:\Program Files\SolidWorks\data\templates\Деталь.prtdot", 0, 0.000000, 0.000000)Part = swApp.ActivateDoc2 ("Деталь1", False, longstatus).ActiveDoc.ActiveView.FrameState = 1= Part.Extension.SelectByID2("Точка1@Исходная точка", "EXTSKETCHPOINT", 0, 0, 0, False, 0, Nothing, 0)= Part.Extension.SelectByID2("Спереди", "PLANE", 0, 0, 0, False, 0, Nothing, 0).InsertSketch2 True.ClearSelection2 True.SketchRectangle 0, 0, 0, 0.1001317919075, 0.07482967244701, 0, 1.ClearSelection2 True= Part.Extension.SelectByID2("Point3", "SKETCHPOINT", 0, 0.07482967244701, 0, False, 0, Nothing, 0)= Part.Extension.SelectByID2("Point2", "SKETCHPOINT", 0.1001317919075, 0.07482967244701, 0, True, 0, Nothing, 0)Annotation = Part.AddHorizontalDimension2(0.100939, 0.092595, 0).ClearSelection2 True.Parameter("D1@Эскиз1").SystemValue = 0.100132.ClearSelection2 True= Part.Extension.SelectByID2("W1@Эскиз1@Деталь1.SLDPRT", "DIMENSION", 0, 0, 0, False, 0, Nothing, 0).ClearSelection2 True= Part.Extension.SelectByID2("Point2", "SKETCHPOINT", 0.10013179191, 0.07482967244701, 0, False, 0, Nothing, 0)= Part.Extension.SelectByID2("Point4", "SKETCHPOINT", 0.10013179191, 0, 0, False, 0, Nothing, 0)= Part.Extension.SelectByID2("Point2", "SKETCHPOINT", 0.10013179191, 0.07482967244701, 0, False, 0, Nothing, 0)= Part.Extension.SelectByID2("Point4", "SKETCHPOINT", 0.10013179191, 0, 0, False, 0, Nothing, 0)= Part.Extension.SelectByID2("Point2", "SKETCHPOINT", 0.10013179191, 0.07482967244701, 0, False, 0, Nothing, 0).ClearSelection2 True= Part.Extension.SelectByID2("Point2", "SKETCHPOINT", 0.10013179191, 0.07482967244701, 0, False, 0, Nothing, 0)= Part.Extension.SelectByID2("Point4", "SKETCHPOINT", 0.10013179191, 0, 0, False, 0, Nothing, 0).SetPickMode.ClearSelection2 True= Part.Extension.SelectByID2("Point4", "SKETCHPOINT", 0.10013179191, 0, 0, False, 0, Nothing, 0)= Part.Extension.SelectByID2("Point2", "SKETCHPOINT", 0.10013179191, 0.07482967244701, 0, True, 0, Nothing, 0)Annotation = Part.AddVerticalDimension2(0.12678, 0.0729455, 0).ClearSelection2 True.Parameter("D1@Эскиз1").SystemValue = 0.0748297.ClearSelection2 True= Part.Extension.SelectByID2("W1@Эскиз1@Деталь1.SLDPRT", "DIMENSION", 0.05760269749518, 0.09205664739884, 0, False, 0, Nothing, 0)= Part.Extension.SelectByID2("H1@Эскиз1@Деталь1.SLDPRT", "DIMENSION", 0.1259722543353, 0.07133044315992, 0, False, 0, Nothing, 0).ClearSelection2 True.InsertSketch2 True= Part.Extension.SelectByID2("Эскиз1", "SKETCH", 0, 0, 0, False, 0, Nothing, 0).ShowNamedView2 "*Триметрия", 8.ClearSelection2 True= Part.Extension.SelectByID2("Эскиз1", "SKETCH", 0, 0, 0, False, 0, Nothing, 0).FeatureManager.FeatureExtrusion2 True, False, False, 0, 0, 0.05, 0.01, False, False, False, False, 0.01745329251994, 0.01745329251994, False, False, False, False, 1, 1, 1, 0, 0, False.SelectionManager.EnableContourSelection = 0.SaveAs2 "C:\Documents and Settings\Администратор\Рабочий стол\Sample1.SLDPRT", 0, FALSE, FALSE.ActiveDoc.ActiveView.FrameState = 1.ClearSelection2 True.ExitAppSub

Скрипт SolidWorks 2006 извлеченный из файла макроса SW_Macro.swpswApp As ObjectPart As ObjectSelMgr As Objectboolstatus As Booleanlongstatus As Long, longwarnings As LongFeature As Objectmain()swApp = Application.SldWorksPart = swApp.ActiveDocSelMgr = Part.SelectionManager.ActiveDoc.ActiveView.FrameState = 1= Part.Extension.SelectByID2("Спереди", "PLANE", 0, 0, 0, False, 0, Nothing, 0).ClearSelection2 True.SketchRectangle 0, 0, 0, 0.1001317919075, 0.07550260115607, 0, 1.ClearSelection2 True= Part.Extension.SelectByID2("Point3", "SKETCHPOINT", 0, 0.07550260115607, 0, False, 0, Nothing, 0)= Part.Extension.SelectByID2("Point2", "SKETCHPOINT", 0.1001317919075, 0.07550260115607, 0, True, 0, Nothing, 0)Annotation = Part.AddHorizontalDimension2(0.0522193, 0.0897687, 0).ClearSelection2 True.Parameter("D1@Эскиз1").SystemValue = 0.100132.ClearSelection2 True= Part.Extension.SelectByID2("Point2", "SKETCHPOINT", 0.10013179191, 0.07550260115607, 0, False, 0, Nothing, 0)= Part.Extension.SelectByID2("Point4", "SKETCHPOINT", 0.10013179191, 0, 0, True, 0, Nothing, 0)Annotation = Part.AddVerticalDimension2(0.118435, 0.0394336, 0).ClearSelection2 True.Parameter("D1@Эскиз1").SystemValue = 0.0755026.ClearSelection2 True.InsertSketch2 True= Part.Extension.SelectByID2("Эскиз1", "SKETCH", 0, 0, 0, False, 0, Nothing, 0).ShowNamedView2 "*Триметрия", 8.ClearSelection2 True= Part.Extension.SelectByID2("Эскиз1", "SKETCH", 0, 0, 0, False, 0, Nothing, 0).FeatureManager.FeatureExtrusion2 True, False, False, 0, 0, 0.05, 0.01, False, False, False, False, 0.01745329251994, 0.01745329251994, False, False, False, False, 1, 1, 1, 0, 0, False.SelectionManager.EnableContourSelection = 0Sub

Скрипт КОМПАС-3Dv10 извлеченный из файла макроса KM_Macro1.m3mKompas6API5 as KAPIwin32com.client import DispatchLDefin2DLDefin3D= Dispatch('KOMPAS.Application.5')= KAPI.KompasObject(iKompasObject)D = iKompasObject.ActiveDocument3D()= iDocument3D.GetPart(LDefin3D.pTop_Part)= iPart.NewEntity(LDefin3D.o3d_sketch)= iSketch.GetDefinition()= iPart.GetDefaultEntity(LDefin3D.o3d_planeXOY).SetPlane(iPlane).Create()D = iDefinition.BeginEdit()D.ksLineSeg(0.0, 0.0, 54.0, 0.0, 1)D.ksLineSeg(54.0, 0.0, 54.0, 41.0, 1)D.ksLineSeg(54.0, 41.0, 0.0, 41.0, 1)D.ksLineSeg(0.0, 41.0, 0.0, 0.0, 1)= KAPI.ksLDimParam(iKompasObject.GetParamStruct(LDefin2D.ko_LDimParam))= KAPI.ksDimDrawingParam(iLDimParam.GetDPar()).Init().ang = 0.0.lenght = 0.0.pl1 = False.pl2 = False.pt1 = 1.pt2 = 1.shelfDir = 0.textBase = 0.textPos = 0= KAPI.ksLDimSourceParam(iLDimParam.GetSPar()).Init().basePoint = 1.dx = 0.0.dy = 24.21979427206.ps = 0.x1 = 0.0.y1 = 41.0.x2 = 54.0.y2 = 41.0= KAPI.ksDimTextParam(iLDimParam.GetTPar()).Init(0).bitFlag = 1.sign = 0.stringFlag = False.style = 3D.ksLinDimension(iLDimParam)= KAPI.ksLDimParam(iKompasObject.GetParamStruct(LDefin2D.ko_LDimParam))= KAPI.ksDimDrawingParam(iLDimParam.GetDPar()).Init().ang = 0.0.lenght = 0.0.pl1 = False.pl2 = False.pt1 = 1.pt2 = 1.shelfDir = 0.textBase = 0.textPos = 0= KAPI.ksLDimSourceParam(iLDimParam.GetSPar()).Init().basePoint = 1.dx = 34.63541688765.dy = 0.0.ps = 1.x1 = 54.0.y1 = 41.0.x2 = 54.0.y2 = 0.0= KAPI.ksDimTextParam(iLDimParam.GetTPar()).Init(0).bitFlag = 1.sign = 0.stringFlag = False.style = 3D.ksLinDimension(iLDimParam).EndEdit()= iDocument3D.GetPart(LDefin3D.pTop_Part)= iPart.NewEntity(LDefin3D.o3d_bossExtrusion)= obj.GetDefinition()= iPart.EntityCollection(LDefin3D.o3d_edge).SelectByPoint(27.0, 0.0, 0.0)= iCollection.GetByIndex(0)= iEdge.GetDefinition()= iEdgeDefinition.GetOwnerEntity().SetSketch(iSketch)= iDefinition.ExtrusionParam().depthNormal = 50.0.depthReverse = 10.0.direction = LDefin3D.dtNormal.draftOutwardNormal = False.draftOutwardReverse = False.draftValueNormal = 0.0.draftValueReverse = 0.0.typeNormal = LDefin3D.etBlind.typeReverse = LDefin3D.etBlind= iDefinition.ThinParam().thin = False.normalThickness = 1.0.reverseThickness = 1.0.thinType = LDefin3D.dtNormal.name = " Операция выдавливания:1"= obj.ColorParam().ambient = 0.5.color = 9474192.diffuse = 0.6.emission = 0.5.shininess = 0.8.specularity = 0.8.transparency = 1.0.Create()

Приложение 2

Задание на Международную олимпиаду по САПР и компьютерному моделированию (приводится в оригинале).

РАЗРАБОТАТЬ САПР ШПОНОЧНЫХ ПРОТЯЖЕК С ВЫДАЧЕЙ РЕЗУЛЬТАТА В ВИДЕ РАСПЕЧАТКИ РАБОЧЕГО ЧЕРТЕЖА ШПОНОЧНОЙ ПРОТЯЖКИ.

Провести расчет для данных, которые приведены ниже.

. ПОРЯДОК РАСЧЕТА ПРОТЯЖКИ

.1. Исходные данные для расчета:

. Диаметр отверстия заготовки D.

. Длина отверстия L .

. Ширина b и глубина шпоночного паза t1 .

. Материал заготовок и протяжки.

Последовательность расчета:

. Рассчитывается величина стрелки C по формуле:

С=0,5(D-)

.

. Устанавливается припуск А, который срезается протяжкой

A=t1 - D + C,

. Конструктивная подача или подъем на зуб на сторону Sz выбирается по таблице 1 (Сначала вибирают максимальную подачу из диапазона).

Таблица 1 Величина подъема Sz на сторону, мм

№ п.пМатериал, который обрабатывается , МПаПодъем на зуб Sz, мм1Сталь< 7500,05-0,202Сталь>= 7500,05-0,123Чугун-0,06-0,204Алюминий-0,05-0,085Латунь, бронза-0,08-0,20

. Глубина впадины зуба протяжки (высота первого зуба)

,

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

Таблица 2 Коэффициенты заполнения стружечной канавки при обработке металлов

Sz, ммСТАЛЬ до 400 МПаСТАЛЬ

от. 400 до 700 МПаСТАЛЬ

более

МПаМедь,

латунь,

алюминийЧугун,

Бронзао 0,033,02,53,02,52,5от 0,03 до 0,074,03,03,53,02,5более 0,074,53,54,03,52,0

. Предварительно определяется шаг режущих и калибрующих зубьев

,

который рекомендуется округлять к ближайшим значениям из нормального ряда шагов зубьев протяжек:

4, 5, 6, 8, 10, 12, 14, 18, 20, 22, 25.

. Проверка шага по наибольшему числу зубьев, которые одновременно берут участие в работе

=.

У полученной при расчете величины Zmax дробная часть отбрасывается, но в любом случае необходимо, чтобы Zmax 3. В противном случае шаг уменьшают, рассчитывая по формуле:

,

а потом опять округляют к стандартному меньшему значению.

. Проверка соотношения между шагом и глубиной стружечной канавки:

;

в случае, когда это неравенство не выпонляется, умельшают величину Sz с шагом 0,01мм до меншего значения из диапазона, указанного в табл.1, и повторяют расчет, начиная с п.п.4. Если м при этом решение не найдено, увеличивают шаг , выбирая следующее большее значение из стандартного ряда.

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

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

Таблица 3 Размеры хвостовиков под кулачковые патроны для шпонковых протяжек

Размеры хвостовика, ммПлощадь опасного сеченияbl1B1H1a1afb1Fхв. мм2670101515204649,48701218152068143,6107015221520610219,61280-28182068224

Примечание. l1 - длина захода хвостовика в тяговый патрон. Dотв. - диаметр отверстия.

. Площадь опасного сечения по канавке первого зуба рассчитывается согласно формул (табл.3):

. Подсчитывается наибольшая сила протягивания в Н по формуле

,

где , х=0,85

. Проверка протяжки на прочность. На проочность протяжки проверяются по впадине первого зуба по формуле

;

и по хвостовику

;

где - допустимое напряжение на разрыв (для быстрорежущей стали =200 МПа, для легированной стали =150 МПа).

У протяжек с хвостовиками под клиновой зажим (табл.3) выполняют еще проверочный расчет на смятие клина по формуле:

.

Тут площадь смятия

где b1 - ширина паза под клин, мм;- ширина шпоночного паза, мм.

Допустимое напряжение смятия :

для легированной стали - =(400-450) МПа ;

для быстрорежущей стали - =600 МПа;

В случае, когда какое-либо условие прочности не выполняется, уменьшают величину Sz с шагом 0,01мм до меншего значения из диапазона, указанного в табл.1 и повторяют расчет, начиная с п.п.4. Если и в этом случае решение не найдено, увеличивают шаг , выбирая следующее большее значение из стандартного ряда и повторяют расчет, начиная з п.п.№6.

. Определяется высота калибрующих зубьев

к = Hхв +A ,

где Hхв - высота хвостовика, мм;- припуск на протягивание, мм.

. Определяется число режущих зубьев

. Рассчитываются размеры режущих зубьев. Высота первого режущего зуба H1 принимается равной высоте хвостовика:

=Hхв

Высота следующих зубьев увеличивается на величину подъема на зуб Sz :

H2=H1+Sz ; H3=H2+ Sz ; H4=H3+ Sz i т.д.

Последние два режущих зуба рассматриваются как переходные, а их высота определяется суммироваанием 0,6 Sz i 0,4 Sz

Необходимо проверить, чтобы высота последнего режущего зуба равнялась высоте калибровочных:

=Hк=Нхв+А

Если это условие не выполняется, корректируют высоту последнего режщего зуба.

. Формируется таблица размеров режущих зубьев по форме:

Тип зубьевРежущиеКалибрующиеДопуск, мм0,01мм0,005ммВысота зуба H, мм Номер зуба1234

. Число каалибрующих зубьев принимают=4

. Суммарная длина протяжки

,

где l - расстояние от торца хвостовика до первого зуба, которая составляет 160мм и выбирается в зависимости от длины передней направляющей, длины направляющей втулки (адаптера), длины хвостовика, который входит в патрон и толщины упорной плиты станка;-длина рабочей части протяжки. Она равна сумме длин режущей и калибрующей частей:

l1=lр+lk .

Длина режущей части

,

а калибрующей

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

Тут Рк - шаг калибровочных зубьев.

. Выполняется проверка на то, чтобы суммарная длина протяжки была не больше допустимой величины, которая приведена в таблице 5.

Таблица 5 Наибольшая допустимая величина шпоночных протяжек

Площадь сечения хвостовика , мм2L доп., мм35500507001909002401000

Если общая длина шпоночной протяжки превышает длину Lдоп., тогда припуск A делится на принятое число проходов n. При этом расчет протяжки проводится для припуска А/n.

Рис. 1. Форма и размеры стружечных канавок черновых зубьев протяжки

. Определяются элементы профиля зубьев протяжки в осевом сечении (рис.1):

ширина спинки ; радиус дна впадины r= 0,50X h; радиус спинки .

. Определяем величины углов: переднего и заднего согласно табл.6.

Таблица 6 Величины переднего угла у протяжек

Обрабатываемый материалУгол g , град.Сталь в МПа 60016Сталь в МПа 600 до 100014Сталь в МПа > 100010Чугун НВ 15010Чугун НВ > 1506Алюминий13Бронза3

Выбирается задний угол :

для режущих зубьев ;

для калибрующих зубьев .

Величина фаски f на режущих зубьях не более 0,05мм, на калибрующих - 0,2-1мм.

. Ширина режущей части протяжки равна:

. Выводятся на экран (по запросу) все рассчитанные результаты, которые относятся к параметрам протяжки.

3.РАЗРАБОТКА РАБОЧЕГО ЧЕРТЕЖА ШПОНОЧНОЙ ПРОТЯЖКИ:

Вычерчивается профиль стружечной впадины между двумя соседними зубьями (рис.1), который состоит из:

·задней поверхности предыдущего зуба шириной С;

·передней поверхности следующего зуба, размещенной под углом , вершина которого находится выше предыдущего на величину подъема на зуб Sz.

·дуги окружности, касательной к передней поверхности и линии, которая определяет глубину канавки h.

·дуги окружности спинки зуба, которая проходит через конец линии задней оверхности, касательно к дуге впадины стружечной канавки.

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

Рис.2.Протяжка шпоночная обыкновенная: 1 - для протяжек, работающих в один проход; 2 - для протяжек, работающих в несколько проходов.

Приложение 3

РАСЧЕТ РАДИАТОРА ПОЛУПРОВОДНИКОВОГО ПРИБОРА

(по материалам [3,21])

Исходные данные

tп.max - максимальная температура перехода;

Rвн - внутреннее тепловое сопротивление прибора;

Ррас - мощность рассеиваемая прибором;

tc - температура окружающей среды;

Rкт - контактное сопротивление прибор - теплосток (величина Rкт лежит в пределах 0,1-1,0 град/Вт).

Последовательность расчета

. Мощность рассеяния прибора при заданных условиях

,

где Rтс - тепловое сопротивление теплосток (радиатор)-среда. Необходимо выполнить условие Рmax > Ррас.

. Тепловое сопротивление теплосток - среда

,

где q - коэффициент, учитывающий неравномерность распределения температуры по радиатору (q » 0,9).

. Среднеповерхностная температура перегрева радиатора (рис. 2.8)

- tc =Ppac · Rтс

. По D t (рис. 2.9) находят минимальную высоту радиатора Lmin.

. Задаются габаритами радиатора: l - ширина радиатора, b - расстояние между ребрами, h - высота ребра, d - толщина основания. Рекомендуется придерживаться следующих соотношений: при основании радиатора 90´ 90 мм; d = 3мм; d = 5 мм; h = 20 мм; b = 12 мм (естественная конвекция) и b = 6 мм (принудительное движение воздуха).

. Расстояние между ребрами

,

где n и d - число и толщина ребра.

Расстояние между ребрами определяют из условия b ³ А, где А толщина пограничного слоя (при естественной конвекции А = 8-10 мм, вынужденной - А » 2,5 мм).

Толщина и высота ребра выбираются из условия

,

где h - высота ребра; a - суммарный коэффициент теплоотвода; l - теплопроводность материала радиатора. Ширину радиатора l определяют из конструктивных соображений, считая l » 0,9 Lmin:

= n (b + d ) - b.

Материалы для радиаторов

g , кг/м3l , Вт/(м· ° С)Медь Сплавы алюминия Сплавы магния Сталь Нержавеющая сталь8960 2660 1760 7840 7840370 160 170 55 14

Степень черноты поверхностей некоторых материалов

Алюминиевый сплав с шероховатой поверхностью Алюминиевый сплав окисленный Алюминиевый сплав анодированный (черный) Медь окисленная0,06-0,07 0,20-0,30 0,80-0,85 0,80-0,88

. Целесообразность оребрения радиатора определяется по критерию Био

i = 0,5ad/l,

< 1 (ребро охлаждается), Bi >1 (ребро изолятор), Bi = 1 (ребро не влияет).

. Всю поверхность радиатора разбивают на части:

S1 - поверхность между ребрами;

S2 - поверхность ребер, обращенная друг к другу;

S3 - поверхность крайних ребер;

S4 - поверхность торцов ребер;

S5 - неоребренная поверхность.

Неоребренная поверхность S5 = l· L

Оребренная поверхность

Sореб= S1+ S2+ S3+ S4=(n-1)· (bLmin)+ 2hl(n-1)+2(h +d)Lmin+ n[ 2hd +d Lmin] .

. Полные коэффициенты теплоотдачи оребренной и неоребренной поверхностей

a гл = a л.гл + a к.гл; a ореб = a л.ореб + a к.ореб; a л = e п· j ij· f(tт,tс).

Для поверхностей S1 и S2 коэффициенты взаимной облученности определяются из графика (рис. 2.10) или рассчитываются

.

Конвективный коэффициент теплоотдачи, Вт/(см2· ? С)

aк = 5,62A(tм)· B,

где tм = 0,5(tт + tc);

Величина А(tм) учитывает свойства среды и находится по графику (рис. 2.11).

Влияние атмосферного давления на величину А(tм) находят из графика рис. 2.12.

. Мощность, рассеиваемая гладкой поверхностью радиатора, Вт,

гл = aгл · Sгл · (tт - tc).

. Величина теплового сопротивления гладкой поверхности, ? C/Вт,

.

. Мощность, рассеиваемая оребренной поверхностью

,

где Рi - мощность, рассеиваемая i-й поверхностью; tic - температура среды между ребрами.

Температура воздуха вблизи поверхностей S3; S4 и S5 равна tc.

Температура воздуха вблизи поверхностей S1 и S2 (между ребрами) равна

tic = tт - (tт - tc)· H,

где H - относительный температурный напор, tт - среднеповерхностная температура теплостока.

Если ребра располагаются вертикально, то

Н = f(h ),

где h = А4(tм)bC, tм = 0,5(tт + tc), C= (tт - tc)1/4/(L)1/4 (рис. 2.13 и 2.14).

ci = tc для S3, S4, S5. tci = tic для S1 и S2 (конвективный коэффициент торцевых поверхностей ребер принимается равным крайним ребрам).

Тепловое сопротивление оребренной поверхности, ° C/Вт

.

Общее тепловое сопротивление

.

Мощность, рассеиваемая радиатором, Вт

Робщ.расч= Ргл + Рореб.

Необходимо выполнить условие Робщ.расч ? Рисх (расч).

Приложение 4

ЛИСТИНГИ ПРОГРАММНОГО КОДА (C#)

ОСНОВНЫХ ФУНКЦИЙ РАЗРАБОТАННЫХ МОДУЛЕЙ

D

//Подключение библиотек для работы с КОМПАС-3DKompas6Constants;Kompas6Constants3D;

//В зависимости от установленной версии подключаються разные библиотеки

#if (__LIGHT_VERSION__)Kompas6LTAPI5;

#elseKompas6API5;

#endifKAPITypes;

// Создаём объекты для работы с КОМПАС-3DKompasObject kompas; // Объект КОМПАС-3DksDocument3D doc3D; // 3D-Документ КОМПАС-3Dstring LastPathCompass; Путь к файлу КОМПАС-3D

// Активируем КОМПАС-3Dvoid ActiveCompass()

{(kompas == null)

{

#if __LIGHT_VERSION__t = Type.GetTypeFromProgID("KOMPASLT.Application.5");

#elset = Type.GetTypeFromProgID("KOMPAS.Application.5");

#endif= (KompasObject)Activator.CreateInstance(t);

}

}

// Открываем файл Компас-3Dvoid OpenFileCompass()

{(kompas != null)

{OpenFileDialog = new OpenFileDialog();.Filter = "КОМПАС-3D Документы (*.m3d;*.a3d)|*.m3d;*.a3d";(OpenFileDialog.ShowDialog() == DialogResult.OK)

{.Text = OpenFileDialog.FileName;= CompassPath.Text;D = (ksDocument3D)kompas.Document3D();(doc3D != null) doc3D.Open(OpenFileDialog.FileName, false);

// Делаем Компас-3D видимым.Visible = true;

}

}

{.Show(this, "Объект не захвачен", "Сообщение");

}

}

// Активируем КОМПАС-3D и открываем файлvoid StartCompass_Click(object sender, EventArgs e)

{();();

}

// Закрываем Компас-3D, закрываем формуvoid Exit_Click(object sender, EventArgs e)

{(kompas != null)

{.Quit();.ReleaseComObject(kompas);

}();

}

// Считываем значение внешних переменных КОМПАС-3Dvoid Compass_EV_Read_Click(object sender, EventArgs e)

{(kompas != null)

{.Visible = true;(doc3D != null)

{(doc3D.IsDetail())

{.ksError("Текущий документ должен быть сборкой");;

}

// Выбор компонента -1 главный(сама сборка),0 первый(первая деталь)part = (ksPart)doc3D.GetPart(-1);(part != null)

{

// Работа с массивом внешних переменныхvarCol =

(ksVariableCollection)part.VariableCollection();(varCol != null)

{var = (ksVariable)kompas.GetParamStruct

((short)StructType2DEnum.ko_VariableParam);(var == null) return;.TableCompassEV.Rows.Clear();(int j = 0; j < varCol.GetCount(); j++)

{

// Считывание переменных с записью в таблицу= (ksVariable)varCol.GetByIndex(j);.TableCompassEV.Rows.Add(var.name, var.value, var.note);

}

}

}

}

}

}

// Запись значения внешних переменных в КОМПАС-3Dvoid Compass_EV_Write_Click(object sender, EventArgs e)

{(kompas != null)

{(doc3D != null)

{(doc3D.IsDetail())

{.ksError("Текущий документ должен быть сборкой");;

}

// Выбор компонента -1 главный(сама сборка),0 первый(первая деталь)part = (ksPart)doc3D.GetPart(-1);(part != null)

{

// Работа с массивом внешних переменныхvarCol =

(ksVariableCollection)part.VariableCollection();(varCol != null)

{

// Запись внешних переменных в компасvar = (ksVariable)kompas.GetParamStruct

((short)StructType2DEnum.ko_VariableParam);(var == null) return;d;g;(int i = 0; i < varCol.GetCount(); i++)

{= (ksVariable)varCol.GetByIndex(i);= (string)(this.TableCompassEV.Rows[i].Cells[1].Value.ToString());= Convert.ToDouble(d);.value = g;

}

//Перестроение сборки, почемуто не работает.RebuildModel();

}

}

}

}

}

VarMathCAD_API

//Подключение библиотек для работы с MathCAD

using Mathcad;

//Создание объектов для работы с MathCAD

private string LastMathCadPath = "";Mathcad.Application MC; //Объектов MathCAD

private Mathcad.Worksheets WK; //Объект для списка рабочих листов MathCADMathcad.Worksheet WS; //Объект для рабочего листа MathCAD

// Активируем MathCADvoid InitMathCad()

{(MC == null)

{

{= new Mathcad.Application();

}

{.Show("MathCAD не установлен.", "Ошибка",.OK, MessageBoxIcon.Error);

}

}

}

// Открываем файл MathCADvoid OpenFileMathCad(string filename)

{(MC != null)

{= MC.Worksheets;(int i = 0; i < WK.Count; i++)

{= WK.Item(i);(WS.FullName == filename).Close(MCSaveOption.mcSaveChanges);

}(WK != null) WS = WK.Open(filename);.Visible = true;

}

{.Show(this, "Объект не захвачен", "Сообщение");

}

}

// Считываем значение входных и выходных переменных MathCADvoid MathCadRead()

{(MC != null)(WS != null)

{(int j = 0; j < 50; j++)

{

{name;= "in" + j; // Считываем значение входных переменных MathCADvalue;

{= (WS.GetValue(name) as NumericValue).Real.ToString();.TableMathCad_IN.Rows.Add(name, value);

}(Exception)

{;

}

}

}(int j = 0; j < 50; j++)

{name;= "out" + j;//Считываем значение выходных переменныхMathCADvalue;

{= (WS.GetValue(name) as NumericValue).Real.ToString();.TableMathCad_OUT.Rows.Add(name, value);

}(Exception)

{;

}

}

}

{.Show(this, "Объект не захвачен", "Сообщение");

}

}

// Записываем значение входных переменных и считываем новые значения выходных // переменных MathCADvoid MathCadWrite()

{(MC != null)(WS != null)

{(int j = 0; j < this.TableMathCad_IN.Rows.Count; j++)

{

{name;= this.TableMathCad_IN.Rows[j].Cells[0].Value.ToString();value;= this.TableMathCad_IN.Rows[j].Cells[1].Value.ToString();var;= ConverToDouble(value);

// Записываем значение входных переменных MathCAD.SetValue(name, var);

}(Exception)

{;

}

}.Recalculate();.Save();(int i = 0; i < this.TableMathCad_OUT.Rows.Count; i++)

{

{name1;= this.TableMathCad_OUT.Rows[i].Cells[0].Value.ToString();value1;

// Cчитываем новые значения выходных переменных MathCAD= (WS.GetValue(name1) as NumericValue).Real.ToString();.TableMathCad_OUT.Rows[i].Cells[1].Value = value1;

}(Exception)

{;

}

}

}

{.Show(this, "Объект не захвачен", "Сообщение");

}

}

VarMathCAD_XML

// Считываем или записываем значения переменных в файл MathCADvoid MathCadParser(string MathPath, bool save)

{

// Обновляем таблицу Маткадаi = 0;region_id;xd = new XmlDocument();{.Load(MathPath); // Открываем файл MathCAD

}

{;

}xnl = xd.DocumentElement.ChildNodes;ml_id, ml_real;(save == false) this.TableMathCad.Rows.Clear();(XmlNode xn in xnl)(xn.Name == "regions")(XmlNode region in xn.ChildNodes)

{_id = region.Attributes[0].Value;(XmlNode math in region.ChildNodes)(XmlNode ml_define in math.ChildNodes)

{(ml_define.Name == "ml:define") // Присвоенные переменные MathCAD

{_id = ml_define.FirstChild;_real = ml_define.LastChild;(ml_real.Name == "ml:real")

{(save == true)_real.InnerText =.TableMathCad.Rows[i].Cells[1].Value.ToString();.TableMathCad.Rows.Add (ml_id.InnerText,_real.InnerText, "Присвоенная", region_id, "define");++;

}

}(ml_define.Name == "ml:eval") // Вычисленные переменные MathCAD

{_id = ml_define.FirstChild;(XmlNode result in ml_define.ChildNodes)(result.Name == "result")

{_real = result.FirstChild;(save == true)ml_real.InnerText = this.TableMathCad.Rows[i].Cells[1].Value.ToString();.TableMathCad.Rows.Add(ml_id.InnerText,_real.InnerText, "Вычисленная", region_id, "eval");

}++;

}

}

}

{(save) xd.Save(MathPath);

}

{.Show("Не могу сохранить! Возможно файл открыт только для чтения!", "Ошибка",MessageBoxButtons.OK, MessageBoxIcon.Error);

}

IntegratorKM_Lite

// Заполняем комбобокс у таблицы MathCAD и выбираем нулевой элементvoid AddMathCadCombo()

{

//заполняем комбобокс у таблицы MathCAD.KompasName_ComboBox.Items.Clear();.KompasName_ComboBox.Items.Add("empty"); (int j = 0; j < TableKompas3D.Rows.Count; j++)

{ .KompasName_ComboBox.Items.Add

(this.TableKompas3D.Rows[j].Cells[0].Value.ToString());

}

// Выбираем нулевой элемент для каждой ячейки в комбо-бокс-столбце в таблице внешних переменных Маткада(int i = 0; i < TableMathCad.Rows.Count; i++)

{.KompasName_ComboBox.DataGridView.Rows[i].Cells[5].Value =.KompasName_ComboBox.Items[0];

}

}

// Заполняем комбобокс у таблицы КОМПАС-3D и выбираем нулевой элементvoid AddKompasCombo()

{

//заполняем комбобокс у таблицы КОМПАС-3D.MathCadName_ComboBox.Items.Clear();.MathCadName_ComboBox.Items.Add("empty");(int j = 0; j < TableMathCad.Rows.Count; j++)

{ .MathCadName_ComboBox.Items.Add

(this.TableMathCad.Rows[j].Cells[0].Value.ToString());

}

// Выбираем нулевой элемент для каждой ячейки в комбо-бокс-столбце в таблице внешних переменных КОМПАС-3D(int i = 0; i < TableKompas3D.Rows.Count; i++)

{.MathCadName_ComboBox.DataGridView.Rows[i].Cells[3].Value =.MathCadName_ComboBox.Items[0];

}

}

// Присваиваем переменной КОМПАС-3D значение переменной MathCAD

// выбранной в комбо-бокс-столбцеEndEdit_TableKompas3D(object sender, DataGridViewCellEventArgs e)

{

{(e.ColumnIndex == 3).TableKompas3D.Rows[e.RowIndex].Cells[1].Value =.TableMathCad.Rows[MathCadName_ComboBox.Items.IndexOf

(this.TableKompas3D.Rows[e.RowIndex].Cells[3].Value)

1].Cells[1].Value;

}

{.Show("Error");;

}

{.TableKompas3D.Update();

}

}

// Присваиваем переменной MathCad значение переменной КОМПАС-3D

// выбранной в комбо-бокс-столбцеTableMathCadCellEndEdit(object sender, DataGridViewCellEventArgs e)

{

{(e.ColumnIndex == 5).TableMathCad.Rows[e.RowIndex].Cells[1].Value =.TableKompas3D.Rows[KompasName_ComboBox.Items.IndexOf

(this.TableMathCad.Rows[e.RowIndex].Cells[5].Value)

1].Cells[1].Value;

}

{.Show("Error");;

}

{.TableMathCad.Update();

}

}

Министерство образования и науки Российской Федерации Государственное образовательное учреждение высшего профессионального образования Ульяновский Госу

Больше работ по теме: