Треугольник ДеЛаПорта — Шильникова: проблемы и решение

Сергей Ренев
Аспирант кафедры деталей машин МГТУ им. Н.Э. Баумана, окончил МГТУ им. Н.Э. Баумана в 2014 году. Имеет несколько научных работ.

Екатерина Столярова
Инженер НАМИ, окончила МГТУ им. Н.Э. Баумана в 2012 году. Имеет несколько научных работ, в том числе статью, представленную на конференции NASA/ESA.

Петр Шильников
К.т.н., доцент МГТУ им. Н.Э. Баумана, в 1979 году окончил МВТУ им. Н.Э. Баумана по специальности «инженер­механик по летательным аппаратам», в 2006­м защитил кандидатскую диссертацию по специальности 05.13.12 «Системы автоматизации проектирования».

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

Признательность

Господин Джеймс ДеЛаПорт (James DeLaPorte) — выдающийся специалист в области компьютерной автоматизации конструкторско­технологической подготовки производства. В деятельности ДеЛаПорта гармонично сочетаются реализация конкретных проектов на предприятиях, участие в международных объединениях, форумах и т.д. и написание концептуальных работ, содержание которых он периодически доносит до слушателей на конференциях и семинарах, вызывая у них неподдельные внимание и восхищение.

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

Термины и определения

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

Источник проблем

Для того чтобы выявить различия, необходимо определить главную особенность. Компьютеризированные процессы отличаются от традиционных производительностью, а именно — высоким быстродействием, возможностью хранить и передавать грандиозные объемы данных на большие расстояния. Но это — отличия количественные, хотя все согласны с тем, что, в соответствии с одним из законов диалектики, количественные изменения могут переходить в качественные. Например, те, кто знаком с практикой работы опытно­конструкторских бюро (ОКБ), имеют представление, сколь существенна роль процессов обработки ПИ (предварительных извещений об изменении [2]). Производительность компьютеризированных процессов позволяет отказаться от ПИ и моментально обеспечивать всем участникам доступ к обновленной версии компьютерного документа. (Несмотря на это, до сих пор встречаются попытки компьютерной автоматизации связанных с ПИ процессов [3]).

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

Суть проблем

Конструкторско­технологическая подготовка производства всегда сопровождается взаимодействием участников [4].

При традиционных процессах участники, обладающие достаточной квалификацией, понимают друг друга, обмениваясь между собой документами, содержащими постановки задач и результаты выполненных работ. При работе с компьютерными документами, если участники пользуются разными программными инструментами, процесс взаимодействия осложняется. Используемые программные инструменты САПР могут быть различными как в пределах одной предметной области (SolidWorks, Inventor, NX, CATIA v5 и пр. — для конструкторов, ANSYS, NASTRAN, Abaqus, Hyper Mesh и пр. — для прочнистов и т.д.), так и на стыке предметных областей (CAD <­> CAM, CAD <­> CAE и т.д.). Обеспечение возможности одного программного инструмента работать с компьютерным документом, созданным другим программным инструментом, является проблемой, требующей решения. При традиционных процессах такой проблемы не возникало (рис. 1).

Рис. 1. Интеграция данных

Рис. 2. Связь интеграции и качества данных

Рис. 3. Проблемы качества данных

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

Инструментом интеграции являются специальные программы преобразования компьютерных документов из одного формата в другой — конверторы. Конверторы являются достаточно сложными программными продуктами. Мало того, что стоимость конвертора может доходить до 40% стоимости основного программного продукта и работа их требует существенных вычислительных ресурсов, в дополнение ко всему этому, в среднем в 5% случаев передачи компьютерных документов между разными САПР возникает ряд проблем. Назовем эти проблемы проблемами качества данных (PDQ — Product Data Quality).

Согласно [6], качество данных — это отсутствие дефектов качества, то есть таких особенностей модели, которые затрудняют ее дальнейшее использование. Конечно, и бумажные документы могут иметь дефекты. Но если, например, на бумажном чертеже косую линию видно сразу и на бумаге же (то есть на кальке­оригинале) этот дефект можно исправить вручную, в компьютерном документе и выявление дефекта, и его исправление требуют программной обработки.

«Дефект качества» — понятие более широкое, чем ошибка. К дефектам качества относятся [8], [7] как фатальные ошибки типа самопересечения кривых и поверхностей, так и «безобидные» разрывы вторых производных, неразличимые на глаз (разрыв второй производной нежелателен при скоростном фрезеровании и для фрагментов конструкции, взаимодействующих с потоками жидкости или газа [8]).

Чаще всего дефекты качества выявляются при передаче компьютерных документов между разными САПР (рис. 2).

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

В высококомпьютеризированных организациях, близких к полному переходу на безбумажные технологии, затраты на обеспечение качества данных достигают 20% от общих затрат на разработку изделия [16]. Убытки от не выявленных своевременно дефектов качества были бы еще больше (рис. 3).

Рассмотренные две проблемы очевидны и проявляются сразу после перехода на компьютеризированные процессы деловой деятельности. Но существует и такая проблема, которая «выжидает» годами и может «нечаянно нагрянуть», когда незадачливый пользователь «ее совсем не ждет». Назовем эту проблему проблемой долгосрочного хранения данных (LTDR — Long Term Data Retention, дословно — «долгосрочное удерживание данных»).

Рис. 4. Треугольник ДеЛаПорта — Шильникова

Для пояснения существа этой проблемы принято приводить самый яркий пример «долгожительства» — бомбардировщик B­52 Stratofortress. Разработка этой машины началась в 1945 году, но до сих пор B­52 является основой стратегической авиации США, а последний летный образец будет списан не ранее 2040 года (итого — жизненный цикл этого изделия составляет 95 лет). Сопоставимую длительность жизненного цикла имеют такие российские самолеты, как Ту­95 и Ту­154. Можно привести множество других схожих примеров из авиационной, ракетно­космической, судостроительной, добывающей, перерабатывающей, энергетической промышленности и других отраслей.

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

Совсем иначе дело обстоит с компьютерными документами. Широко распространенные в 1970­е годы компьютеры IBM 370, PDP­11, VAX, CAD­системы ANVIL 4000, CIS Medusa, Applicon воспринимаются ныне как ископаемые, и прочесть компьютерные документы, созданные этими инструментами, сейчас вряд ли возможно, в то же время разрабатывавшийся одновременно с ними Boeing 767 летает и поныне. Естественно, возникает проблема, и проблема серьезная: как сохранять компьютерные документы на протяжении многих десятилетий.

Конечно же, B­52 разрабатывался на кульмане, а в упомянутые 1970­е годы компьютер был не основным инструментом разработки, а вспомогательным средством, позволявшим более быстро и качественно производить всё ту же бумажную документацию. Тем не менее можно ожидать, что появившиеся совсем недавно Boeing 787 и Airbus A350, созданные уже при практически полной компьютерной автоматизации, будут так же, как и их предшественники, существовать десятилетия.

Видна связь этой третьей проблемы с двумя предыдущими: если мы озабочены долгосрочным хранением компьютерных документов, то такие документы должны быть упорядочены, взаимоувязаны, то есть интегрированы, и должно быть обеспечено приемлемое качество данных этих документов. Очевидно, что три рассмотренные проблемы взаимосвязаны. Назовем треугольник, образованный этими проблемами, «Треугольником ДеЛаПорта — Шильникова» (рис. 4).

Если проблемы взаимосвязаны, то и их решение должно быть общим.

Решение проблем

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

Инкапсуляция предполагает, что все компьютерные документы остаются в формате породивших их программных инструментов САПР. Суть подхода — в учете документов, то есть создании полного списка, где для каждого документа указываются обозначение, наименование, назначение, происхождение, связи с другими документами и сведения о том, какими средствами может быть открыт документ. При таком подходе легко обеспечить управление составом изделия, включая управление конфигурацией (configuration management), а вот построить модель сборочной единицы, составные части которой разработаны в различных CAD­системах, уже не получится.

Под интерфейсом понимается преобразование компьютерных документов из формата передающей САПР в требуемый формат. Это может быть формат принимающей САПР или некоторый другой формат, чаще — «нейтральный». Нейтральный формат — это формат, не являющийся внутренним форматом какого­либо программного инструмента САПР и предназначенный для обмена данными и/или хранения данных в архиве. Спецификации наиболее развитых нейтральных форматов приняты в качестве стандартов — как национальных (IGES), так и международных (STEP, JT, 3D PDF и т.д.). Поскольку не существует ни одной коммерческой САПР, для которой нейтральный формат является ее собственным внутренним форматом, для работы с документами в нейтральных форматах всегда используются уже упоминавшиеся выше конверторы.

Под интеграцией понимается «глубокая переработка», включающая работу как с данными, так и с метаданными. Созданный в соответствии с таким подходом документ содержит как описание всех необходимых свойств изделия, так и подробное описание природы этих свойств, описание описаний свойств и так далее, вплоть до простейших, не раскрываемых далее понятий. Попытки создать методологию таких интегрированных моделей не прекращаются, начиная с разрабатывавшихся как стандарты ISO проектов ISO 14959 PAREX (интеграция прорабатывалась в перспективной части проекта Parametrics) и ISO 18876 IIDEAS. Первый получивший практическое применение стандарт — ISO 15926. Хотя он и носит официальное название «Oil&Gas», более развернуто — «Представление данных жизненного цикла нефтегазового оборудования», охватываемая им предметная область гораздо шире, проще сказать — необъятна.

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

Первыми нейтральными форматами были DXF и IGES, а также некоторые другие, уже забытые, как, например, VDA FS и пр. В настоящее время наиболее развитым нейтральным форматом является ISO 10303 STEP. Сопоставлять STEP и XML не имеет смысла, XML — лишь основа для создания семейства форматов, основанных на XML (таких форматов довольно много, например 3D XML, PDM XML и пр., при этом постоянно появляются новые представители семейства).

В [13] приведен анализ пригодности наиболее распространенных нейтральных форматов для различных сценариев деловой деятельности. При этом в тех случаях, когда преимущество отдается не STEP, а другому формату, причина такого предпочтения кроется не в ограниченности возможностей STEP, а в слабости программных реализаций. Например, при рассмотрении сценария визуализации формат STEP, по мнению авторов, уступает форматам 3D XML, JT и 3D PDF. Но в действительности причина этого — в отсутствии широко распространенных мощных визуализаторов STEP. Тем более что в последней версии конструкторского протокола AP242 STEP (ISO 10303­242 «Managed model based 3d engineering») добавлена возможность хранения результатов тесселяции. Следовательно, вся информация, требуемая для построения высококачественных изображений, может быть представлена средствами формата STEP.

Рис. 5. Преимущество нейтральных форматов

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

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

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

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

Рассмотрим проблему качества данных. Она не столь очевидна, как проблема интеграции данных, и для решения этой проблемы требуется проведение исследований. Эти исследования были начаты Союзом автопроизводителей Германии VDA (Verband der Automobilindustrie) в конце 1980­х
годов, когда компьютеризация процессов конструкторско­технологической подготовки в отрасли достигла такого уровня, при котором неудачи в работе с компьютерными документами стали серьезным препятствием при разработке изделий. Результатом исследований были выпущенные в октябре 1993 года Рекомендации VDA4955 [14]. В этой работе перечислены наиболее часто встречающиеся и затрудняющие работу «дефекты качества» (правда, в то время термина «дефект качества» еще не существовало). Конечно же, подробное описание проблемы — это еще не ее решение, но, тем не менее, стало понятно, на какие вероятные дефекты в компьютерных документах следует обращать внимание. Рекомендации VDA4955 стали исходными данными для разработки программных модулей проверки и, по возможности, — исправления компьютерных конструкторских документов.

Рис. 6. Проверка наличия дефектов модели одним из коммерческих «чекеров»

Появившиеся в последующие годы документы, развивающие и уточняющие содержание Рекомендаций VDA4955, не получали такой всемирной известности и признания, как первоначальный документ VDA4955, до тех пор, пока не появился новый документ SASIG PDQ [8].

В SASIG PDQ набор описываемых дефектов качества гораздо шире, как шире и охват предметных областей: рассматриваются уже дефекты не только конструкторских документов, приводится классификация дефектов, на основе которой введена система кодовых обозначений, например G­ED­TI (Geometry­Edge­Tiny) — крошечное ребро в геометрической модели, или G­CU­IS (Geometry­Curve­Intersection) — самопересекающаяся кривая в геометрической модели. В документ включены сводные таблицы, шаблоны отчетов, пример методики расчета затрат.

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

Одновременно с разработкой всех этих методик, рекомендаций и руководств продолжалось создание их программных реализаций — как в форме встроенных модулей, присутствующих ныне практически во всех CAD­системах, так и в форме отдельных «чекеров». Если Q­Checker фактически является дополнительным модулем CATIA, то существуют и обособленные программные продукты: CADDoctor, CADFix, TransVidia и т.д. (рис. 6).

Знаменательной вехой в развитии методик, рекомендаций и руководств стало появление нового тома формата STEP — стандарта ISO 10303­59 [7]. Стандарт разработан на основе SASIG PDQ.

Том ISO 10303­59 относится к информационным ресурсам и не предназначен для непосредственного применения. Информационные ресурсы используются в составе Прикладных протоколов STEP [4]. Первым таким Прикладным протоколом стал AP242.

Информационные объекты (сущности — entity), содержащиеся в ISO 10303­59, а следовательно, заимствованные в Протоколе ISO 10303­242, позволяют записывать разнообразные данные, относящиеся к проверке качества данных. В число отражаемых аспектов качества данных входят и общее описание выполненных процедур проверки, и описание конкретных обнаруженных дефектов. Существенным преимуществом при этом является возможность указать точное место обнаруженного дефекта и связанные с этим дефектом геометрические примитивы (рис. 7).

Рис. 7. Возможности Протокола ISO 10303-242
по формальному представлению обнаруженного дефекта качества

Итак, при практическом решении второй проблемы — проблемы качества данных, с появлением томов ISO 10303­59 и ISO 10303­242 формат STEP также стал занимать особое место. Только в соответствующей AP242 STEP модели изделия можно иметь однозначную, точную, доступную как для просмотра человеком, так и для программной обработки информацию о качестве данных компьютерного документа, содержащего модель изделия, включая точное описание обнаруженных дефектов качества. Наличие точного описания дефекта качества — предпосылка устранения этого дефекта.

Решение третьей проблемы — проблемы долгосрочного хранения данных — также началось с исследований. Исследовательский проект LTDR (Long Term Data Retention — долгосрочное «удерживание» данных, то есть сохранение данных доступными для обработки на протяжении длительного срока), 2000 год, выполнялся основанным Исследовательским объединением Южной Каролины (SCRA — South Caroline Research Association) всемирным консорциумом PDES (Product Data Exchange Specification — Спецификация обмена данными об изделии). Консорциум PDES объединяет организации, участвующие в разработке формата ISO 10303 STEP, в разработке программных реализаций формата STEP и в его практическом применении в промышленности.

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

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

В результате выполненного исследования окончательное предпочтение было отдано пункту 7 — «Использование нейтральных форматов».

В 2005 году проект LTDR был объединен со схожим по направлению проектом LOTAR (LOng Term Archiving and Retrieval — Долгосрочное архивирование и извлечение данных), выполнявшимся консорциумом ProSTEP iViP — европейским аналогом консорциума PDES. Возник проект LOTAR Aerospace, который в 2008 году был преобразован в проект LOTAR International. Проектом LOTAR International управляют два сопредседателя (в алфавитном порядке): Жан­Ив Делоне (Jean­Yves Delaunay) от компании Airbus и Рик Зюрей (Rick Zuray) от компании Boeing. В последние годы усилия проектной группы LOTAR International сосредоточены на разработке двух параллельных серий стандартов: EN9300 и NAS9300. В этих стандартах содержатся указания по использованию формата ISO 10303 STEP для долгосрочного архивирования данных об изделии. И в решении этой проблемы формат STEP занимает особое место, хотя враги STEP не дремлют: например, в проектную группу LOTAR уже поступало предложение использовать в качестве основного инструмента долгосрочного хранения формат JT. Остается полагаться на благоразумие Ж.­И. Делоне и Р. Зюрея, ведь для решения проблемы долгосрочного хранения данных об изделии особо критичны стабильность и однородность используемых средств решения проблемы.

Выводы

Рост компьютерной автоматизации производства наряду с несомненными преимуществами влечет за собой появление новых проблем, которых не было в докомпьютерную эпоху. Основной источник этих проблем — зависимость компьютерных данных от аппаратных и программных компьютерных инструментов, что приводит к появлению трех взаимосвязанных проблем: проблемы интеграции данных, проблемы качества данных об изделии и проблемы долгосрочного хранения данных. На решении этих проблем сосредоточены усилия большого числа специалистов в области компьютерных наук. Формат ISO 10303 STEP является самым приемлемым средством решения обозначенных проблем. 

Литература:

1. ГОСТ Р ИСО 10303­1­99. Системы автоматизации производства и их интеграция. Представление данных об изделии и обмен этими данными. Часть 1. Общие представления и основополагающие принципы.
2. ГОСТ 2.503­90. Единая система конструкторской документации. Правила внесения изменений.
3. Дружков К.А., Колесов Е.В., Зенкова М.Г. Решение по синхронизации электронных архивов. Презентация. Материалы XI международной конференции по PLM. Москва, 30 октября 2014 г.
4. Шильников П.С. Представление данных КИП. Интернет­ресурс, постоянный адрес: http://www.plm­consulting.ru/pdf/cip_data_2009­11­01.pdf
5. Kjell A. Bengtsson (2004) Using ISO 10303, Express, the information Modeling language, to create advanced Solutions for Industrial Data Applications. Overview of World­wide Projects: Proceedings of 18th European Conference on Object­Oriented Programming. Oslo 14­18 June 2004. Интернет­ресурс, постоянный адрес: http://ecoop04.at.ifi.uio.no/docs/KjellBengtsson.pdf
6. Ренев С.А., Столярова Е.Л., Шильников П.С. Шерстяной треугольник качества. САПР и графика. 2015. № 7. С. 72­74.
7. ГОСТ Р ИСО 10303­59­2012. Системы автоматизации производства и их интеграция. Представление данных об изделии и обмен этими данными. Часть 59. Интегрированные обобщенные ресурсы. Качество данных о форме изделия.
8. ISO/PAS 26183 Product Data Quality (D15) v_2
9. Howard Mason (2014). Evolving Standards to Drive a Thriving Business Proceedings of 3D CIC ‘14. Colorado Springs, Co, May 28­29.
10. Tomasz Luniewski (2014). Importance of CAD Data Quality & Validation in MBE Technical Data Package (TDP). Proceedings of 3D CIC ‘14, Colorado Springs, Co, May 28­29.
11. Catherine Stolyarova (2012). Recursive Data Conversion for PDQ management. Proceedings of the 5th International Workshop on System & Concurrent Engineering for Space Applications (SECESA). Lisbon, Portugal, 2012. Интернет­ресурс, постоянный адрес: http://www.congrexprojects.com/docs/12c12_docs/1130­stolyarova.pdf?sfvrsn=2
12. Peter Shilnikov (2012). The ontology of healing of product shape data for ISO 10303 STEP. Proceedings of the 5th International Workshop on System & Concurrent Engineering for Space Applications (SECESA). Lisbon, Portugal, 2012. Интернет­ресурс, постоянный адрес: http://www.congrexprojects.com/docs/12c12_docs/0935­shilnikov.pdf?sfvrsn=2
13. Dr. Arnulf Fröhlich (под редакцией). White Paper: 3D Formats in the Field of Engineering — a Comparison. Интернет­ресурс, постоянный адрес: http://isicad.ru/uploads/http___www.prostep.pdf.
14. VDA 4955: VDA recommendation — Scope and Quality of CAD/CAM Data.
15. PLM Harmonization Center EADS SSC (Strategic Standardization Committee) Overview of NAS/EN 9300 LOTAR standards and ISO STEP AP 242 «managed model based 3D Engineering» Example of use of LOTAR and STEP AP 242 within Airbus ISO /TC 183 /SC 4 workshop, Paris Afnor Industry Day — 5 th of June 2013.
16. Thomas C. Redman. Data Quality and Society Proceedings of Information Impact International Conference San Diego, CA Sept 2003.
17. James DeLaPorte. Model Based Enterprise Impact on Organizational Behavior. Proceedings of 3D CIC ‘12. Colorado Springs, Co, May 21­23.
18. Charles Chen, James DeLaPorte. Institutionalization of Interoperability Behaviors. Proceedings of GPDIS 2012, Chandler, Az Nov 12­15. Интернет­ресурс, постоянный адрес: http://www.elysiuminc.com/gpdis/2012/2Boeing%20Open­Chen­DeLaPorte­Institutionalization%20of%20Interoperability­11­14­12.pdf
19. James DeLaPorte. Data consistency, Interoperability, and Longevity for FAA Certification of 3D MBD Systems. Proceedings of COE 2009 Annual PLM Conference & Technifair. Seattle, Wa, Apr 19­22.
20. James DeLaPorte. Strategy, Standards & Tools to Accelerate Certification. In Proceedings of the Collaboration and Interoperability Congres

САПР и графика 1`2016