АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомДругоеЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция

Стандарты обмена данными между САПР

Читайте также:
  1. D) постоянных затрат к разнице между ценой реализации продукции и удельными переменными затратами.
  2. E) Для фиксированного предложения денег количественное уравнение отражает прямую взаимосвязь между уровнем цен Р и выпуском продукции Y.
  3. ERP-стандарты и Стандарты Качества как инструменты реализации принципа «Непрерывного улучшения»
  4. I Раздел 1. Международные яиившжоши. «пююеям как процесс...
  5. I. О различии между чистым и эмпирическим познанием
  6. II. Операции над векторами, заданными их разложениями по ортам (заданными координатами)
  7. II. Типы отношений между членами синтагмы
  8. III. Разрешение споров в международных организациях.
  9. IV. О различии между аналитическими и синтетическими суждениями
  10. PINTNAME (А. Международное наименование)
  11. А). Расчет стоимости одного комплекта гуманитарной помощи с помощью функции СЛУЧМЕЖДУ
  12. Аббревиатура и термины, используемые при международных морских грузоперевозках

 

Прикладные САПР, например программы генерации сетки для анализа по методу конечных элементов или траектории движения инструмента станков с ЧПУ, требуют на входе технического описания продукта. Данные технического описания делятся на два типа. Первый тип – это данные чертежа, включающие векторное описание линий и технические требования имеющиеся на чертеже (значения размеров, допусков, символов, комментарии и т.п.). Второй тип – представление трехмерной модели с пояснительными данными. Поэтому данные технических требований обычно импортируются из CAD-системы. Однако, CAD-системы хранят результаты проектирования в своих собственных структурах данных, формат которых зависит от конкретной САПР. Они могут не соответствовать входному формату используемой прикладной САПР. Таким образом, когда две или более CAD/CAM/CAE-системы объединяются и связываются в единое приложение для совместного использования данных, часто возникает проблема обмена данными. Фактически всегда имеется потребность связать воедино несколько систем либо внутри одной организации, либо внешне, как в случае со смежниками или поставщиками компонентов.

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

 

2.3.1. Методы обмена данными технических требований

 

Различные CAD/CAM/CAE-системы хранят данные в разных форматах, поэтому для переноса данных необходима программа-конвертер, преобразующая данные технических требований одной системы в формат другой системы. Еще один конвертер нужен для передачи данных в обратном направлении. Следовательно, для каждой пары систем необходимо иметь два конвертера. Эти конвертеры для каждой конкретной пары систем называются прямыми конверторами (direct translators). Если у нас есть n различных систем, нам необходимо разработать n(n-1) конвертеров, поскольку количество пар систем равно n(n­–1)/2. Например, для обмена данными между 10 системами придется разработать 90 конвертеров. Таким образом, метод прямого конвертирования непрактичен, так как требует разработки слишком большого количества конвертеров при необходимости работать со множеством систем. Более того, добавление одной системы к n уже имеющихся потребует написания 2n дополнительных конвертеров.

Обмен данными можно обеспечить, введя нейтральную структуру данных, называемую нейтральным файлом (neutral file). Таким образом, в каждой системе будет своя пара конвертеров для экспорта и импорта данных в нейтральный формат. Конвертер, преобразующий данные из собственного формата в нейтральный называется предпроцессором (pre-processor). Конвертер, преобразующий данные из нейтрального в формат определенной системы, называется постпроцессором (post-processor). Соответственно, в этом случае для обмена данными между n системами потребуется 2n конвертеров. Это метод обмена данными получил название косвенного метода. Благодаря наличию всего двух конвертеров для каждой системы косвенный метод принят в качестве главного метода обмена данными между различными системами. Однако у этого метода тоже имеются некоторые недостатки. В частности, прямые конвертеры работают быстрее косвенных, и создаваемые ими файлы имеют меньший размер, чем нейтральные файлы. При переносе данных через нейтральный файл, некоторая информация, как правило, теряется, особенно информация о топологическом дереве и о ограничениях в системах параметрического моделирования.

Далее мы рассмотрим три типичных формата нейтрального файла: IGES (Initial Graphics Exchange Specification – первоначальная спецификация обмена графическими данными), DXF (Drawing Interchange Format – формат обмена чертежами) и STEP (STandard for Exchange of Product model data – стандарт обмена данными о модели продукта). В настоящее время IGES является самым популярным форматом нейтрального файла, а формат DXF используется главным образом для обмена чертежами. STEP – это стандартный формат данных, используемый для хранения полной информации обо всем жизненном цикле продукта, включая проектирование, анализ, производство, контроль качества, испытания и обслуживание помимо обычных данных технических требований. В настоящее время CAD-системы, поддерживающие формат IGES, ориентированы на переход к формату STEP.

 

2.3.2. Формат IGES

 

IGES был первым стандартным форматом обмена данными, разработанным для передачи данными между различными САПР. Ранние версии IGES были ориентированы на CAD/CAM системы 1970-х и начала 1980-х гг., то есть главным образом для обмена чертежами. В более поздних версиях был расширен спектр данных, подлежащих обмену. Например, версия 2.0 поддерживала обмен данными анализа по методу конечных элементов и данными печатных плат, в версии 3.0 были расширены возможности пользовательских макрокоманд, играющих важную роль при обмене стандартными библиотеками деталей, в версии 4.0 была введена поддержка дерева CSG, а в версии 5.0 появилась обработка данных структуры B-Rep.

IGES-файл состоит из шести разделов, которые должны идти в следующем порядке: Flag (Флаг, необязательный раздел), Start (Начало), Global (Глобальные данные), Directory Entry (Запись в каталоге), Parameter Data (Параметрические данные), Terminate (Конец). Пять обязательных разделов идентифицируются буквами S, G, D, P и Т, в столбце 73.

Данные в IGES-файле могут быть представлены в двух форматах: ASCII и бинарном. Формат ASCII имеет две разновидности: фиксированную длину строки 80 символов и сжатую форму. Сжатая форма это ASCII-файл, сжатый путем устранения пробелов между записями. Бинарный формат это двоичное представление данных в виде потока битов в формате с фиксированной длиной записи. Чтобы идентифицировать формат файла в столбец 73 раздела Flag записывается символ С если это сжатый ASCII-файл, или символ В если это бинарный файл. Раздел Flag отсутствует, если это ASCII-файл с фиксированной длиной строки 80 символов.

В разделе Start дается описание файла в форме, воспринимаемой человеком. В нем указывается система, являющаяся источником данных, предпроцессор и описываемый продукт.

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

Раздел Directory Entry содержит список всех элементов и некоторых их атрибутов. В IGES-файле все данные технических требований представлены в виде списка предопределенных элементов: геометрических (линии, кривые, плоскости, поверхности) и пояснительных (комментарии и значения размеров). Каждому элементу присваивается определенный номер типа.

Раздел Parameter Data содержит фактические данные, описывающие каждый из элементов, перечисленных в разделе Directory Entry. Например, элемент, представляющий собой прямую линию, определяется шестью координатами двух ее конечных точек. Параметрические данные указываются в свободном формате в столбцах 1-64. Разделитель полей, определенный в разделе Global, используется для разделения параметров, а определенный там же разделитель записей – для обозначения конца списка параметров. Обычно в качестве разделителя полей используется запятая, а в качестве разделителя записей – точка с запятой.

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

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

 

2.3.3. Формат DXF

 

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

DXF-файл – это текстовый файл в формате ASCII, состоящий из пяти разделов: Header (Заголовок), Table (Таблица), Block (Блок), Entity (Элемент) и Terminate (Конец). В разделе Header описывается среда AutoCAD, в которой был создан DXF-файл. В разделе Table содержится информация о типах линий, слоях, стилях текста и видах, которые могут быть определены в чертеже. В разделе Block содержится список графических элементов, определенных как группа. Конкретные данные по каждому элементу хранятся в разделе Entity. Раздел Entity – это главный раздел DXF-файла, в котором описываются все элементы, присутствующие на чертеже.

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

 

2.3.4. Формат STEP

 

Форматы IGES и DXF были разработаны для обмена данными технических требований, а не данными о продукте. Под данными о продукте мы понимаем данные, относящиеся ко всему жизненному циклу продукта (например, проектирование, производство контроль качества, испытание и поддержка). Хотя спецификации IGES и DXF были расширены с целью включения некоторых из этих данных, информации, содержащейся в этих файлах, по существу недостаточно для описания всего жизненного цикла продукта. Вследствие этого в США в 1983 году началась разработка нового стандарта PDES, затем перешедшего в STEP.

В основе разработки STEP лежат следующие принципы:

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

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

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

STEP разрабатывается рядом комитетов и рабочих групп, занимающихся разными частями стандарта. Эти части группируются по методам описания, интегрированным информационным ресурсам, прикладным протоколам, методам реализации и методологией согласования.

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

Сегодня STEP привлекает к себе повышенное внимание, так как ожидается, что он войдет в систему стандартов технологий CALS как стандарт обмена данными о продуктах. Цель инициативы CALS, автором которой является Министерство обороны США, –компьютеризация процесса формирования требований, заказа, эксплуатации, поддержки и обслуживания систем вооружений, используемых в армии США. Особое внимание эта инициатива уделяет заданию форматов, которые будут использоваться для хранения и обмена компьютерными данными. Хотя CALS создавалась для военных целей, она становится промышленным стандартом хранения и обмена компьютерными данными в организации.

 


1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |

Поиск по сайту:



Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Студалл.Орг (0.004 сек.)