Содержание к диссертации
Введение
ГЛАВА 1 Проблемы реализации процедур преобразования данных в интегрированных системах CAD/САМ 25
1.1 Обзор основных существующих обменных форматов данных 25
1.2 Причины многообразия обменных форматов данных 31
1.3 Влияние различных форматов на функционирование CAD/CAM-систем 33
1.4. Постановка задачи исследования: CATJ/CAM-системы и конвертеры 34
ГЛАВА 2 Программно-алгоритмическая методика построения конвертеров обменных форматов 36
2.1. Подходы к преобразованию форматов CAD/CAM-систем 36
2.2. Реализация и преимущества конвертера с «подключаемыми» динамическими библиотеками 39
2.3. Применение динамически подключаемы библиотек в светя СОМ-технологии 44
2.4. Реализация механизмов обмена данными 49
ГЛАВА 3 Вопросы разработки программно-математического обеспечения конвертеров форматов данных 51
3.1 Внутренние структуры данных. Общие функции математического объекта. 52
3.2. Внутренний формат представления данных 62
3.3. Выбор NURBS в качестве внутреннего представления кривых и поверхностей 68
3.4. Проблемы сохранения точности и валидации внутреннего формата 73
ГЛАВА 4 Практика применения разработанных методик 84
4.1. Совместимость различных CAD/CAM-систем на уровне обменных файлов 84
4.2. Применение внутреннего обменного формата 88
4.3. Практическое использование программно-математических средств конвертеров форматов данных в интегрированных системах CAD/САМ 90
Основные выводы по работе
Литература
- Причины многообразия обменных форматов данных
- Применение динамически подключаемы библиотек в светя СОМ-технологии
- Внутренний формат представления данных
- Практическое использование программно-математических средств конвертеров форматов данных в интегрированных системах CAD/САМ
Причины многообразия обменных форматов данных
Информационное обеспечение в большинстве своём представляет большую базу данных, которая постоянно обновляется. Эта база данных содержит в себе те сведения, которые необходимы для успешной работы автоматизированной системы [16, 19]. В этом подразделе рассматривается характерная база данных для CAD/САМ - системы, то есть её строение (подразделение на модули) и сведения, которые содержатся внутри этих модулей.
В информационном обеспечении CAD/САМ - систем существуют свои особенности. База данных у них делится как бы на две части. Основную часть составляет база данных этапа технологического проектирования процессов обработки, а другая составляющая включает в себя графическую информацию, которая представляет собой готовые сведения по всем смоделированным ранее объектам на данной системе. Эти сведения могут содержаться в отдельных файлах, которые могут загружаться пользователем, и в случае сходства графической информации ранее смоделированного объекта с графической информацией моделируемого в настоящее время объекта, использоваться им на этапе проектирования изделия. Если система является параметрической (например, T-Flex CAD), то часть базы данных содержит геометрические образы типовых деталей или сборочных единиц (болты, гайки, подшипники,...) [24]. Благодаря параметрическим связям, наложенным на детали из базы, они будут автоматически изменять свои геометрические размеры по требованиям ЕСКД при изменении соответствующих участков чертежа конструктором.
Такова типичная база данных в CAD - системе.
Гораздо более сложной является информационное обеспечение в САМ или основная часть (базы данных) CAD/САМ - систем. Внутри этой части в настоящее время принято выделять следующие информационные модули, или блоки [25, 32]:
1. данные по станкам - как правило, включают в себя марку станка по маркировке фирмы - изготовителя, характеристики станка (его основные геометрические размеры, частоту оборотов шпинделя, мощность приводов, количество координат и максимальное перемещение по ним) и так далее;
2. данные по инструменту - обычно это основной размер инструмента (для сферических фрез, например, таковым является диаметр рабочей части, диаметр хвостовика и длина инструмента), тип инструмента, рекомендуемые для данного инструмента режимы резания (глубина резания, скорость резания и подача), маркировка инструмента по документации фирмы - изготовителя,
3. данные по специальным инструментальным принадлежностям - указываются их характерные размеры и с каким инструментом используются;
4. свойства материалов - обычно они уже заранее заложены в том модуле информационного обеспечения, где описывается сам инструмент (так как каждый тип инструмента предназначен для обработки определённого материала);
5. технологические данные - в данном случае имеются в виду те данные (вернее данные тех технологических процессов), которые уже были спроектированы с использованием данной автоматизированной системы. Такова структура современного информационного обеспечения автоматизированных систем. Но самое важное, чтобы система могла работать с созданной базой данных. Имеется в виду выбор нескольких вариантов для этапов конструирования и проектирования технологического процесса обработки детали и их предложение пользователю. Всё это возможно только в том случае, если база данных довольно обширна, обладает современными и актуальными на настоящий момент сведениями и выполнена на соответствующем программном обеспечении [32]. В настоящее время существует множество различных систем управления базами данных (в дальнейшем СУБД), но разработчики используют в основном такие СУБД, которые являются универсальными, то есть могут работать с различными операционными системами и быть совместимыми с другими СУБД и приложениями. Таким образом, можно выделить основное направление в разработке информационного обеспечения: принимать во внимание и учитывать максимальное количество факторов, влияющих на разработку технологического процесса изготовления изделия и на процесс проектирования этого изделия, постоянно совершенствовать и формировать новые сведения в базе данных, а также обновлять старые, а кроме того обеспечивать совместимость базы данных со многими СУБД с целью, предоставить возможность обновления в ней сведений конечным пользователем (это необходимо в том случае, если база данных разработана с использованием одной СУБД, а у пользователя другой вид СУБД). Такая концепция сформулирована и применяется в настоящий момент такими фирмами - разработчиками автоматизированных систем, как «Exapt» и «ICEM» (последняя является отделением фирмы "Control Data"). Лингвистическое обеспечение в современных видах автоматизированных систем
Основное предназначение лингвистического обеспечения заключается в том, что оно призвано максимально облегчить работу пользователя и предоставить максимум удобств при работе с автоматизированной системой /8,9/. Понятно, что в этих целях применяется множество различных решений. Но принятие того или иного решения зависит, прежде всего от того, с какой операционной системой призвана работать та или другая система CAD, САМ или CAD/САМ. В этом разделе рассматриваются возможные варианты лингвистического обеспечения под операционные системы WINDOWS и MS - DOS, которые являются разработками фирмы «Microsoft».
Применение динамически подключаемы библиотек в светя СОМ-технологии
Также в главе 4, изделие (продукт) описывается в терминах геометрической и негеометрической информации, при этом негеометрическая информация подразделяется на аннотацию, определение продукта и сведения об организации. Геометрический раздел содержит такие элементы, как точки, кривые, поверхности и твёрдые тела, которые представляют собой модель продукта. Раздел аннотации состоит из тех элементов, которые используются для уточнения или усиления геометрии, включая такие возможности, как размерные линии, чертёжные надписи и текст. Раздел определения продукта обеспечивает возможность определить специфические свойства или характеристики конкретных «сущностей» или наборов «сущностей», содержащих данные. Раздел организации идентифицирует принципы создания групп элементов геометрических, организационных и аннотационных данных, с которыми можно манипулировать, как с обычными одиночными данными.
Стандарт ISO STEP.
Стандарт ISO 10303 STEP (Standard for Exchange of Product data) является ключевым стандартом среди информационных CALS-стандартов. Для некоторых из стандартов (ISO 13584 Р LIB, ISO 15531 Maxidata, ISO 14959 Parametrics) STEP определяет единые используемые во всех этих стандартах средства описания данных и общую идеологию, для других стандартов (SGML, EDIFACT) должна быть обеспечена совместимость со стандартом STEP как с ключевым стандартом [38, 39, 40].
Формат STEP интегрирует понятия в предметной области «промышленное производство продукции», то есть представляет единую информационную модель этих понятий в виде, формализованном на уровне спецификаций объектно ориентированного языка Express. STEP обеспечивает единое представление информации модели изделия в форме группы ресурсов (описаний и структуры), которые вместе поддерживают полное и однозначное определение изделия. Достоинством стандарта STEP является наличие формального определения предметной области средствами языка Express. Компиляция облегчает обработку определения предметной области и позволяет выделить то подмножество, которое необходимо конкретному пользователю.
Стандарт VDA FS.
VDA FS появился в связи с тем, что существовала задача организовать обмен графическими данными между разработчиками автомобилей и станкостроительными предприятиями [37]. Тем самым последние могли выпускать необходимое оборудование и оснастку для автостроительных компаний, а кроме того закладывать необходимое представление графической информации в программное обеспечение своего оборудования. Также в качестве дополнительного требования была выдвинута простота работы с VDA FS и простота его реализации внутри автоматизированных систем CAD, САМ и CAD/САМ. Разработка осуществлялась в отделах CAD/САМ -систем таких автомобильных фирм, как «BMW», «VW», «Opel», «Porsche», «Daimler -Benz» и на станкостроительных фирмах или фирмах связанных со станкостроением «Hella», «Bosch». Сами разработчики надеялись, что за счёт своей простоты употребления формат VDA FS получит мировое распространение. Это подтверждается тем фактом, что в новых версиях большинства автоматизированных систем имеется возможность работы с этим форматом.
Графический формат DXF.
Формат DXF является обменном форматом, используемом в системе AutoCAD фирмы AutoDesk, впервые появившейся на рынке в 1982 г. [7]. С тех пор система "получила необычайно широкое распространение. Она успешно применяется в различных областях приложений: машиностроении, архитектуре, электронике -практически везде. Формат DXF - это основной формат для обмена чертежами между AutoCAd-ом и другими системами. Формат внутренних файлов системы - файлов чертежей (DWG-файлы) является конфиденциальной информацией фирмы AutoDesk Inc. и к тому же претерпевает изменения от версии к версии Формат внешних же файлов остается практически неизменным.
Структура файла DXF эквивалентна структуре файла чертежа (DWG), имеющего двоичный формат. Однако в данной работе он не рассматривается по причинам, изложенным выше. Файлы обмена описаниями чертежей содержат почти всю информацию, необходимую для воспроизведения чертежа. Это основной источник документированной графической информации. Одним необходимым элементом, отсутствующим в DXF файлах, является описание графических символов и шрифтов. Эти описания могут быть найдены в файлах графических символов и шрифтов (SHX-файлах).
Файлы типа DXF разделяются на четыре отдельные секции. Если какая-либо система самостоятельно создает файл формата DXF, то в него можно включать только те секции, которые важны для воспроизведения этого чертежа.
Внутренний формат представления данных
В качестве хранилища объектов внутреннего формата был выбран простой одномерный массив указателей на базовый объект с возможностью динамического изменения размера. Преимущества такого подхода очевидны (мы получаем возможность мгновенного индексированного доступа к любому элементу, например, запомнив нужный индекс при обработке). Кроме того, динамическое изменение размера предоставляет нам возможность не «заботиться» о размере массива. В случае статического выделения памяти приходится или сразу выделять произвольно большое количество памяти, или помещать вызов процедуры изменения размера выделенного блока (ре-аллокирования) непосредственно в код программы в необходимых местах. Благодаря средствам ООП, в частности, перегрузке операций [28], многие действия скрыты от пользователя. Например, перегрузив оператор «[ ]», мы получаем возможность обращаться к элементам массива, использую привычный синтаксис всех языков программирования, и избавляемся от необходимости явного вызова функции, пусть даже и с понятным именем для совершения очевидного действия.
В диссертационной работе применяется класс, основанный на динамическом массиве. Ниже приводится описание этого класса, включая все необходимые для работы с ним методы. Данный класс является надстройкой над классом РАггау, и предоставляет удобный интерфйес для работы с набором геометрических элементов. //главный класс, содержащий внутренний список сущностей class EntityManager { РАггау Geometricltem Item List; public: EntityManager() {RemoveAII();}; //добавить элемент void Addltem(Geometricltem it) {ItemList.Add(it);}; //удалить все void RemoveAIIO {ltemList.RemoveAII();}; Geometricltem & Getltem( UINT item_n) const {return ltemUst[item_n];}; Geometricltem & operator []( UINT item_n ) const {return lteml_ist[item_n];}; UI NT GetSize(void) {return lteml_ist.Count();}; }; В свою очередь, класс Раггау реализован как класс-шаблон [28]. (см. Приложение. 1)
Еще один аргумент в пользу массива указателей на объекты. Как следует из описания операционной системы Microsoft Windows [1], указатель (не void ) занимает в памяти 8 байт (реализация для платформы Microsoft Windows, 32-bit, Intel х8б processor family). При этом указатель всегда занимает в статической памяти одинаковое число байт, независимо от того, на объект какого типа он указывает. Назовем размер указателя РУ. Таким образом, собственно массив указателей занимает в статической памяти объем S, равный РУ . N байт, где N - число элементов массива. Это во много раз меньше, чем если бы мы стали размещать в статической памяти собственно объекты, а не указатели на них. Данное замечание справедливо как для 16-ти, так и для 32-х разрядной платформы, хотя и с разных точек зрения. Для 16-ти разрядной платформы важно, чтобы S был меньше, чем размер сегмента (что составляет всего 65535 байт). Для 32-х разрядной платформы такого строгого ограничения нет. Однако чрезмерный расход памяти в 32-х разрядных платформах, особенно в Windows 9x/NT ведет к существенному замедлению работы. Это связано с тем, что Windows использует виртуальную организацию памяти [1]. Следовательно, очень большие запросы на выделение памяти ведут к увеличению, времени работы программы.
Обратимся к рассмотрению реализации методов класса Geometricltem. Часть методов в нем объявлены как виртуальные методы. Виртуальность, вообще говоря, это одно из важнейших свойств ООП. Это свойство неоднократно будет использовано в нашей работе, «...если у статических методов код и экземпляр объекта связываются во время компиляции, то у виртуальных связь устанавливается во время выполнения программы... Суть виртуального метода заключается в общности использования его действия по одному и тому же имени всеми объектами дерева иерархии, при этом каждый из объектов реализует это действие по-своему. Виртуальность как понятие в данном случае говорит о том, что при вызове такого метода программиста больше интересует само действие, чем конкретный экземпляр, посредством методов которого оно будет производиться».[5]
Geometricltem ItemList[i] Geometricltem MbCartPoint3D MbCircle3D MbSpline Surface IsA IsA IsA IsA Эти методы являются виртуальными и задают полиморфизм объектов Transform Transform Transform Transform DistanceToPoint2 In it SetKnots Рис. 3.1 Виртуальные методы базового класса и их перегрузка в классах-потомках
Рассмотрим, как работает механизм виртуальных функций. Вышеприведенная схема (рисунок 3.1) иллюстрирует работу виртуальных функций - мы имеем массив указателей на объекты типа Geometricltem, вызываем виртуальную функцию (описанную в базовом классе), но на самом деле вызывается функция, принадлежащая реально созданному в памяти объекту (потомку Geometricltem). Если бы эти функции были объявлены как не как виртуальные, то вызывалась бы функция, того типа класса, указатель на который мы имеем, в данном случае - определенная в базовом (!) классе. То есть, имея массив указателей на объекты типа Geometricltem, и вызывая, скажем, функцию IsA, мы получаем всегда один тип - 0. Следовательно, мы бы не смогли узнать тип элемента. Не зная фактический тип элемента, мы не можем выполнить приведение к нужному типу (для вызова функций, которые описаны в потомке). Следует заметить, что пункты 3-6 (приведение типа) имеет смысл выполнять лишь тогда, когда используются функции, не описанные в базовом классе. В противном случае происходит потеря времени на ненужные преобразования к типу.
Более того, всю предложенную методологию работы с некоторыми допущениями можно рассматривать как пример виртуального подхода (в виде позднего связывания). Ведь исполняемому модулю не известно, как именно реализована функция экспорта или импорта. Реализация определяется самим источником.
Практическое использование программно-математических средств конвертеров форматов данных в интегрированных системах CAD/САМ
Однако даже в том случае, когда разработчик системы предусмотрел возможность чтения диалектов, могут появиться трудности и ошибки, связанные с реализацией конкретных математических методов для работы с сущностями, записанными в обменных файлах. Примером может служить работа с обменным файлом формата IGES.
Иногда абсолютно правильные с точки зрения экспортирующей системы файлы зачитываются другой системой с ошибками, или вообще не читаются. Самый наглядный случай - это работа с сущностями rationalbsplinecurve и rational_b_spline_surface. При записи параметров этих сущностей последними записываются минимальный и максимальный параметры функции. Фактически это задаёт обрезку по параметру (А,(и) и a(u, v)). Но внутри списка параметров пишутся значения начального и конечного узлов. Многие системы-источники (конвертеры) производят перепараметризацию этих сущностей (особенно при обрезке сплайна трехмерными вершинами), в результате чего после сохранения значения узлов оказываются точно такими же, а вот параметры обрезки изменяются таким образом, что выходят за границы, заданные узлами. В результате этого система-приемник не всегда может корректно обработать такую сущность.
В заключение приведем еще несколько примеров неудачной реализации процедур чтения обменных файлов.
Согласно требованиям стандарта, в конце IGES файла должен записываться эпилог, содержащий дополнительную служебную информацию, такую, как число строк в секции каталога, параметров, заголовка, и т.д. Такие системы, как SolidEdge, Duct вообще отказываются читать IGES файл, если при сканировании обнаруживается разница между реальным числом строк в разных секциях, и значением, записанным в эпилоге, хотя эта информация никакой роли не играет. Также некоторые системы требуют, чтобы «хвостовой» ноль (т.е. если дробная часть равна нулю) в вещественных числах обязательно присутствовал. В противном случае системы выдают сообщение о некорректности файла, хотя информация при записи не подвергалась округлению, и потерь точности не происходило.
Но даже если разработчик успешно преодолел все вышеуказанные трудности, очень важной может оказаться просто популярность формата. Несмотря на то, что формат STEP, по мысли ISO, должен был вытеснить собой формат IGES, этого пока не произошло. Более того, наличие диалектов, трудность в получении стандартов (в нашей стране тома стандартов стоят около 4 тыс. долларов), ошибки при записи обменных файлов, заставляет многих разработчиков заказывать или писать самим программы 88
конвертеры из одного промышленного формата в другой. К примеру, обменные файлы формата IGES, создаваемые системой CATIA вызывают нарекания со стороны пользователей. Однако файлы формата STEP CATIA сохраняет абсолютно правильно. С другой стороны, STEP пока «понимают» далеко не все CAD/САМ системы. IGES гораздо более популярен (см. табл. 3.2)
Таким образом, можно сделать вывод о необходимости всестороннего анализа факторов, сопровождающих процесс разработки конвертеров обменных файлов.
При распространении конвертера с подгружаемыми библиотеками одной из задач становится полноценная поддержка (сопровождение) и развитие данного продукта на всем жизненном цикле. Поддержка включает в себя снабжение конечных пользователей обновленными или исправленными версиями библиотек, устранение обнаруженных ошибок.
Развитие подразумевает создание новых библиотек для конвертера. Для того, чтобы в полном объеме реализовать все преимущества разработанного подхода необходимо своевременно создавать библиотеки для возникающих у пользователя задач. Идеология пакета снимает ограничение как на процесс создания библиотек, так и на количество одновременно подключенных модулей. Существуют два варианта разработки. Первый - разработка библиотек ведется самим пользователем. Второй -автором или уполномоченным распространителем пакета (дилером).
Рассмотрим оба варианта. В первом случае схему работы между заказчиком и исполнителем можно представить в виде следующей последовательности: 1. Выдача заказчиком технического задания на разработку 2. Снабжение Исполнителя необходимой документацией по формату 3. Выполнение Исполнителем необходимых работ по созданию новой библиотеки 4. Тестирование Заказчиком текущей версии 5. Доработка Исполнителем версии в соответсвии с требованиями заказчика 6. Получение Заказчиком готового программного продукта. Во втором случае пользователь сам разрабатывает новые версии библиотек под свои собственные нужды. В этом случае возникает вопрос об открытости внутреннего формата и доступности/стоимости специальных математических библиотек, предназначенных для создания новых модулей конвертера.
Если разработчик даёт право пользователю самому создавать программное обеспечение, то он обязан снабдить его документацией, подробно описывающюю принципы обмена информацией и требования к вновь создаваемым библиотекам. Кроме того, пользователь должен получить от разработчика набор специальных математических библиотек.
Рассматривая оба подхода, можно выявить особенности каждого из них. В первом случае стоимость разработки отностительно невелика, и рассчитывается исходя из сложности нового формата (стоимость разработки = базовая стоимость + сложность нового формата). Отрицательными сторонами этого варианта, в свою очередь, являются необходимость постоянно поддерживать связь с исполнителем, как на этапе разработки, так и на этапе тестирования и сопровождения; а также при создании новых модулей заключать новый договор с исполнителем. Вследствие этого снижается мобильность и скорость разработки.
В случае самостоятельной разработки пользователем новых модулей процесс программирования происходит непосредственно на месте, что исключает временные и финансовые затраты. Однако при этом пользователю необходимо приобрести математические библиотеки для работы с внутренним форматом. Покупка этого ПО производится однократно и, в дальнейшем, пользователь работает с ним, используя заложенные в нем возможности. Этот математический аппарат также может быть использован при решении широкого круга задач в области проектирования и построения CAD/САМ систем, поэтому цена, установленная разработчиком на соответвующее ПО может существенно превышать финансовые возможности Заказчика. Приведём пример. В настоящее время существует несколько фирм, которые наряду с программными продуктами продают и математическое ядро для разработки пользовательских приложений. Наиболее известными являются ACIS (фирмы Spatial technologies) и Parasolid (фирмы Unigraphics). Пользователь этого математического ядра обязан производить отчисления (т.н. royalties) в счет фирмы с каждой проданной копии своей CAD/САМ системы, базирующейся на этом ядре.
