isicad.ru :: портал САПР, PLM и ERP :: версия для печати

Статьи

3 декабря 2012

Трансляция данных САПР сегодня

Эван Ярес

От редакции isicad.ru: Предлагаем вниманию читателей перевод статьи давнего друга isicad Эвана Яреса о технологических предпосылках остроактуальной проблемы трансляции данных САПР.

Проблема трансляции данных давно находится в фокусе нашего внимания — и как разработчиков, и как журналистов (см. опубликованные ранее на нашем портале материалы «Кого хвалить и кого ругать за трансляцию данных и прямое моделирование», «Форматы данных: кто виноват и как с этим бороться?», «Proficiency — параметрические инструменты для трансляции данных».

Мы и принимали участие в создании транслятора параметрических моделей из CATIA в SolidWorks, поэтому знакомы с проблематикой на собственной шкуре. Вот почему в разрабатываемое сейчас с нашим участием Российское Геометрическое Ядро (см. «Специалисты ЛЕДАСа — об участии компании в создании российского геометрического ядра») мы заложили архитуктуру, которая позволит импортировать в него чужие модели с минимальными проблемами.

Оригинал статьи на английском языке

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

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

Kubotek Validation Tool отображает разницу между исходной и оттранслированной моделями.


NURBS и B-reps
Современные трехмерные машиностроительные САПР, как правило, используют примерно один и тот же принцип представления данных. На верхнем уровне находятся сборки. Уровнем ниже — детали и, отдельно, чертежи. Детали определены либо параметрически, либо явно, но в любом случае их топология определяется твердотельной моделью с граничным представлением (т.н. B-Rep), созданным из набора обрезанных поверхностей NURBS (non-uniform rational B-spline — неоднородные рациональные В-сплайны). B-Rep можно представить как костюм аквалангиста, сшитый из отдельных кусков. Если костюм сшит качественно — он будет водонепроницаемым, если же швы имеют много зазоров — костюм будет протекать.

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

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

Я несколько утрирую, говоря, что проблема допусков является ключевой проблемой в трансляции данных САПР. Хотя многие люди в нашей отрасли придерживаются такого мнения — но не делает утверждение правдой. Недавно я беседовал с доктором Полом Сталлингсом (Dr. Paul Stallings), руководившем в прошлом разработкой геометрического ядра ACIS, сейчас он работает в Kubotek. Пол рассказал мне, что проблема точности и допусков для него является одной из самых простых проблем в области обмена данными.

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

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

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

С допусками, по словам Сталлингса, главная проблема состоит в том, что одни системы работают с рассекающими контурами в трехмерном пространстве, а другие работают с ними в параметрическом двумерном пространстве, спроецированном на поверхности. Расхождение между параметрическим и трехмерным пространствами создает огромную проблему при обмене данными между ACIS и Parasolid, использующими трехмерное пространство и между CATIA или Pro/E, работающими с параметрическим пространством. IGES и STEP могут использовать как одно из этих описаний, так и оба вместе. Сталлингс утверждает, что имеется слишком много файлов, одновременно содержащих и 2D, и 3D кривые — и эти кривые, не используемые записывающей системой, являются ошибкой. В IGES пытаются решить эту проблему, предлагая при записи выставлять соответствующий флажок, обозначающий кривые, которыми можно пользоваться. По иронии судьбы, существование такого флага само по себе есть «признание вины», так как если бы оба типа кривых могли использоваться, то такой флаг был бы вовсе не нужен. Если вы уловили нить рассуждений Сталлингса, мои поздравления: Вы — истинный САПРист. Сталингс, никогда не уклоняющийся от высказывания своего мнения, также указал на то, что, когда файлы САПР будут эффективно экспортироваться из дорогих систем, люди будут покупать меньше таких рабочих мест, предпочитая перенести данные в менее дорогие системы. Таким образом, у поставщиков дорогих систем есть мотив, чтобы не делать этот процесс простым.

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

Кроме этого, есть заметное количество компаний, которые используют эти компоненты для создания отдельных приложений для трансляции и проверки данных САПР. Среди этих компаний — ITI TranscenData, Theorem Solutions, Elysium, Capvidia, TransMagic и Core Technologie. Возможно, вы удивитесь, что существуют так много таких компаний, ведь системы САПР имеют свои функции импорта и экспорта. Но на это есть три причины: во-первых, не все программы САПР могут импортировать и экспортировать все форматы файлов. Во-вторых, отдельные трансляторы (как минимум, большинство из них) работают более качественно и надежно, чем встроенные средства импорта и экспорта. И, в-третьих, компании, производящие отдельные трансляторы, предлагают больше возможностей и автоматизации для работы с задачами, возникающими у крупных авиакосмических и автомобилестроительных компаний.

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

Считалось, что использование различных способов параметризации в разных САПР делает работу с их файлами проблематичной.

Даже САПР от одного поставщика могут представлять данные разными способами. Для описания винглета в CATIA V4 требовалось 13 поверхностей, в CATIA V6 для этого понадобилось уже 226 поверхностей.

Несколько лет назад инвесторы вложили более $40 млн. в Proficiency, компанию, которая намеревалась разрешить проблему трансляции данных с историей построения. Но им этого не удалось, в конце концов, в 2009 компания была куплена компанией ITI TranscenData. Люди из ITI сообщили мне, что они теперь могут транслировать 95% данных с историей построения. Пожалуй, этого уже недостаточно по нынешним временам. В настоящее время инструменты Proficiency обычно используются при массовой миграции с одной САПР на другую.

Необходимость в трансляции данных с историй построения несколько смягчилась с появлением САПР с продвинутыми возможностями прямого редактирования геометрии, такими как Solid Edge, Kubotek, SpaceClaim, IronCAD и Creo Direct. Эти программы могут работать в сущности «мертвыми» данными САПР. В частности, они популярны для создания предварительного концептуального дизайна или подготовки моделей для использования в системах CAE.

Другая тенденция, затрагивающая трансляцию данных САПР, — использование информации о производстве изделия (Product and Manufacturing Information, PMI) и цифрового определения продукта (model-based design, MBD). Основная идея MBD состоит в том, чтобы поместить всю информацию, необходимую для изготовления детали, непосредственно в ее 3D файл, чтобы избавиться от использования 2D чертежей. Крупные авиастроительные компании развивали эту концепцию в течение последнего десятилетия, но лишь год или два как она стала приобретать популярность вне аэрокосмической отрасли.

Использование MBD влияет на трансляцию данных САПР, так как привносит еще один уровень сложности в 3D файлы САПР. Теперь помимо трансляции геометрии, программы должны правильно обработать все аннотации. PMI чаще называют GD&T (Геометрические размеры и допуски — англ. Geometric Dimensioning and Tolerancing)или FT&A (Functional Tolerancing & Annotation, Автоматизированный процесс проставления геометрических размеров и допусков), в зависимости от того, с каким вендором САПР вы имеете дело. Вся эта функциональность описана в стандарте ANSI Y14.41.

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

Несколько типичных процессов, которые используют трехмерные данные. Модель двигателя MRAP CAT I A1 создана в компании SURVICE Metrology.

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

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

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

Программы проверки данных САПР, такие как CompareWorks компании Capvidia, могут найти ошибки, которые сама САПР проигнорирует.

Решением этой проблемы является проверка данных. Значительное число компаний предлагает приложения для проверки данных САПР, отображающие разницу между геометрией в исходном файле и оттранслированным файлом. В числе этих компаний — ITI TranscenData, Theorem Software, Elysium, TransMagic и Kubotek. Компания Capvidia предлагает уникальную программу проверки данных CompareWorks, работающую внутри SolidWorks.

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

Все права защищены. © 2004-2024 Группа компаний «ЛЕДАС»

Перепечатка материалов сайта допускается с согласия редакции, ссылка на isicad.ru обязательна.
Вы можете обратиться к нам по адресу info@isicad.ru.