Современная организация проектирования мехатронных систем в вузах. Облачные решения и управление проектом в среде Siemens Teamcenter

Ольга Огородникова
Д.т.н., доцент, профессор кафедры электронного машиностроения, Уральский федеральный университет (УрФУ).
Владимир Власов
К.т.н., доцент, технический директор ГК «ПЛМ Урал».

Анализ текущей проблематики проектирования в интегрированных программных средах CAD/CAE/CAM/PLM

Этапы компьютеризации проектирования

Основываясь на тридцатилетнем опыте внедрения программных комплексов CAD/CAE/CAM/PLM для проектирования и подготовки производства в машиностроении, мы можем выделить несколько этапов компьютеризации проектирования CAD/CAE. На первом этапе конструкторские бюро отказались от черчения карандашом, заменили кульманы на компьютеры и перешли к созданию электронных чертежей. На втором этапе акценты в геометрическом моделировании сместились с плоских чертежей 2D на объемные модели 3D. На третьем этапе внимание проектировщиков переместилось от геометрии CAD к физике процессов и расчетному обоснованию проекта в программах CAE, где построенная геометрическая модель подвергается многодисциплинарному исследованию, включая разрушение (краш­тесты) и движение в потоке [1, 2]. На текущем, четвертом этапе происходит переход от проверочных расчетов CAE к оптимизационным, принципиальное отличие которых заключается в том,  что анализ функциональности изделия проводится на более ранних стадиях проектирования, одновременно с построением геометрии, и обосновывает редактирование геометрической модели в расчетных итерациях [3, 4].

Направления развития в управлении проектными данными

Объем проектной информации постоянно увеличивается, что требует развития методов организации и управления данными в рамках идеологии PLM [5, 6]. Ситуация на российских предприятиях усугубляется  инсталляцией большого количества не связанных между собой программ. Можно выделить четыре проблемных направления в развитии методов организации проектной информации.

Первое направление — централизация информации

Поскольку все рабочие места проектировщиков компьютеризованы, создается большой объем рассредоточенной информации, которая сохраняется на локальных компьютерах или на сервере. При этом файлы передаются между локальными компьютерами по электронной сети или через переносные устройства, для чего создается множество рабочих копий. В процессе проектирования выполненные изменения и корректировки вносятся отдельными сотрудниками в локальные рабочие копии, и в результате появляются неактуальные копии, которые способны генерировать проектные ошибки в массиве несогласованных данных. По текущему состоянию дел возникает необходимость централизованно хранить информацию на сервере и оперативно согласовывать изменения с использованием специализированных управляющих программ. Такую функцию централизованного управления данными может выполнять, например, модуль Teamcenter от компании Siemens PLM Software [7]. Реорганизация в этом случае затрагивает только информационный сектор проектирования в рамках используемой компьютерной сети, без изменений в количестве и качестве рабочих мест и серверов. В централизованной информационной среде специалисту на локальный компьютер поступает извещение о том, что он получил право доступа к конкретной детали, и задание выполнить назначенную часть работы (например, провести прочностной расчет, разработать технологию и т.п.). Далее специалист заходит на сервер, забирает необходимую информацию на свое рабочее место, работает с деталью, делает замечания и возвращает добавленные данные на сервер. Централизация данных в первую очередь приводит к тому, что исчезают неконтролируемые копии, поскольку информация существует в единственном варианте и она всегда актуальна. Новая организующая функция, которая появляется в связи с централизацией, заключается в разграничении прав доступа к информации.

Второе направление — структуризация информации

Информация, объединяющая конструкторскую CAD/CAE­ и технологическую CAM­подготовку производства, должна быть централизована и организована в структуру. В основе структуры находится изделие, соответственно, в его электронной структуре выделяется сектор сборочной единицы и далее — подсборки, узла, детали [8]. Так, в сектор детали помещается объемная модель, а также чертеж, свойства материала [9], результаты расчетов на прочность и т.д., то есть вся информация, связанная с этой деталью. Структуризация информации, связь данных со структурой обеспечивает быстрый поиск необходимых файлов.

Третье направление — электронная модель

В соответствии с действующими стандартами последней редакции [10], при проектировании создается электронная модель изделия, которая включает электронный макет с геометрическими файлами и технологическую информацию. Следует отметить различие в проставлении размеров на чертежах и в электронных моделях. Чертеж выполняется для того, чтобы восстановить геометрию, и предоставляет все необходимые для этого размеры. Электронная модель показывает объемную геометрию в таком формате, в котором ее можно непосредственно использовать для изготовления детали и технологической оснастки на станках с ЧПУ [11]. Любой номинальный размер в электронной модели создается при построении, его можно быстро высветить средствами измерения CAD, и нет необходимости специально указывать. В электронной модели проставляются только технологические размеры, сообщающие дополнительную информацию о допусках, предельных отклонениях, шероховатости и т.п. Поэтому электронная модель позволяет организовать дальнейший процесс проектирования и согласование проектной документации без чертежей — как бумажных, так и электронных. Плоские чертежи при использовании электронной модели не требуются, поскольку не содержат уникальной информации, только дублируют имеющиеся в модели данные.

Четвертое направление — управление данными

Управление проектными данными  переходит в систему PLM, которая ставит под свой контроль движение информации между участниками проекта [12]. Еще совсем недавно конструктор, выполнив чертеж, должен был позвонить нормоконтролеру и передать ему работу по сети или на внешнем носителе. Сейчас процесс согласования информации, централизованной и структурированной в привязке к электронной модели, можно организовать иначе. Как только появилась новая информация, например конструктор создал объемную модель детали, запускается бизнес­процесс, в котором прописано, что эта модель должна пойти сначала на нормоконтроль, потом — начальнику конструкторского бюро на утверждение и далее — технологу. Всем участникам отправляется извещение с указанием, что необходимо сделать. В свою очередь, нормоконтролер, получив извещение, проверил деталь, нашел ошибки и вернул конструктору на доработку, либо согласовал, тогда информация идет дальше по цепочке в соответствии с бизнес­процессом.

Проблема унификации проектных данных

Поскольку плоские чертежи уходят из практики машиностроительного проектирования и в связи с этим изменяется характер работы нормоконтролера, возникает необходимость в разработке новых принципов унифицированного представления проектных данных. Ранее нормативной базой для проверки конструкторской документации служили стандарты ЕСКД, в которых четко обозначены все правила оформления и структурирования чертежей, вплоть до толщины линий. Аналогичных стандартов по созданию и структурированию 3D­моделей пока не существует. Некоторыми крупными зарубежными производителями, такими как Bosch или Siemens, формируются корпоративные правила, которые распространяются только на создание электронной документации внутри корпорации и не являются обязательными для прочих пользователей. Вместе с тем, такие правила становятся актуальными для крупных проектов и определяют идеологическое построение систем PLM.

Первую успешную практику разработки и применения стандартов компьютерного моделирования 3D CAD к комплектации электронных документов участниками большого проекта (100 млн деталей) представляют создатели коллайдера в CERN [13]. Приступив к сборке моделей CAD, полученных от многочисленных поставщиков, организаторы проекта обнаружили несовместимое разнообразие принципов объемных построений и расположения данных в дереве построений. Тогда для смежных проектировщиков (5700 активных участников) были сформулированы общие правила организации данных при создании объемных моделей CAD, которые регламентировали распределение информации по слоям, расположение размеров в определенных слоях, цветовое обозначение твердотельных и оболочечных объектов и т.п.

Аналогичные усилия по разработке универсальных принципов организации электронной проектно­конструкторской документации прилагаются крупными российскими корпорациями, прежде всего — в авиакосмической отрасли [14]. Так, компания «Гражданские самолеты Сухого» осуществляет хранение всех нормативных справочных и инженерных данных в системе Teamcenter, посредством которой проводится согласование, утверждение, проведение изменений конструкторской документации. Учитывая наличие сложных кооперативных связей на всем протяжении производственной цепочки, решение вопроса унификации данных и автоматизации обмена данными имеет принципиально важное значение. Все участники проекта, например, располагают размеры в установленном слое, что позволяет при объединении составных частей в сборку отключить неактуальные слои для контроля размеров.

Проектирование в облаках — проблема аппаратного обеспечения

В инженерную деятельность активно подключаются облачные технологии, которые предоставляют удобную среду для хранения и обработки информации, объединяющую аппаратные средства, лицензионное программное обеспечение и быстрые каналы связи. Благодаря этому в последнее время решается вопрос увеличения и неограниченного масштабирования информационных ресурсов и мощностей, недоступных для индивидуального владения. Вместе с тем, проектирование становится ресурсоемким. Необходимые аппаратные ресурсы способны предоставить многие дата­центры, включая крупнейшие: Amazon, Google, Azure [15].

Перспективной средой для реализации проектирования в облаках представляется платформа Teamcenter, которая обеспечивает межпользовательский графический интерфейс и инструменты отображения, редактирования, создания данных. Существует две концепции в организации проектирования в облаках: «тонкий клиент» и «толстый клиент». Основанный на веб­технологиях тонкий клиент (веб­клиент) не требует установки лицензионного программного обеспечения в полном объеме на рабочих местах пользователей. При этом мощные вычислительные ресурсы сосредоточены на сервере, где фактически ведутся проектные работы и сопутствующие вычисления. Загруженный работой сервер распределяет задачи и посылает пользователям информацию на экран — он может обеспечить одновременную работу 50 инженеров в действующем проекте. Основная проблематика в использовании тонких клиентов при проектировании связана с настройкой и организацией центрального сервера.

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

Проектирование в облаках — проблема лицензионного обеспечения

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

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

Электронная модель и идеология PMI (Product Manufacturing Information)

Важной составляющей информационной структуры, окружающей электронную модель в облаке, является информация о технических условиях, которую может использовать технолог для изготовления. Сама модель без технических условий несет только вспомогательную роль, представляя геометрию детали, в соответствии с которой можно оценить массу и габаритные размеры, и далее спроектировать оснастку, подготовить управляющие программы для станка с ЧПУ. Ключевой момент — нанесение на модель отклонений формы, но по текущим требованиям в российском машиностроении допуски, посадки, шероховатости наносятся на чертеж, и в этом заключается проблема, ограничивающая подготовку производства в облаке с применением автоматизированных и роботизированных комплексов [17]. К технологу отправляется чертеж, выполненный по модели, поэтому специалист вносит изменения в чертеж. В результате чертеж накапливает в себе все изменения, при этом исходная модель, как правило, не подвергается изменениям, не содержит технологическую информацию и по мере накопления изменений теряет связь с чертежом. Технологу приходится заново создавать трехмерную модель по актуальному согласованному чертежу, чтобы подготовить программу ЧПУ. Таким образом, идеология PMI принципиально меняет подход к сквозному проектированию, привязывая информацию к модели и позиционируя чертеж как вспомогательный объект проектирования, который создается для сторонних поставщиков и специалистов, не имеющих возможности работать непосредственно с моделью в программной среде.

Проблема согласования проекта

Идеология PMI предполагает отказ от чертежа как ключевого документа для согласования проекта, в том числе — смежными службами. Именно в согласующий документ вносятся все изменения, которые после утверждения становятся обязательными к исполнению; сюда входят не только размеры деталей, но и качество поверхности, технологические указания (хромировать, закалить и т.п.). На текущий момент в полном объеме правила согласования с участием электронной модели не сформулированы. Согласование легко проходит внутри конструкторского бюро по этапам проектирования, включающим эскизный проект (базовая контрольная структура, схемы), технический проект (электронный макет, подробно построенная геометрическая модель изделия), рабочий проект (собственно электронная модель, геометрическая модель и технологическая информация). Но экономисты и снабженцы во внутреннем согласовании не участвуют и модель при переходе на предпроизводственный этап для комплектации и поставки материалов и покупных изделий в свои отделы не получают. Между тем, для быстрого и точного исполнения принципиально важно подключать к согласованию проекта экономистов и снабженцев на ранних стадиях, уже на этапе технического проекта, а технологов — на этапе эскизного проекта. Такой подход позволяет избежать многочисленных переделок от корневых позиций, когда специалисты за пределами конструкторского бюро отказываются согласовать готовый проект, потому что нет соответствующего оборудования или появились иные модификации двигателей на рынке. В свою очередь, проделав большую работу, конструктор, как правило, отказывается вносить масштабные изменения в проект и стремится его согласовать по текущему состоянию. Технически в среде Temcanter коммуникации с внешними службами обеспечиваются разнообразием разрешенных к размещению форматов: в некоторых случаях информация дублируется в формате PDF и становится доступной для широкого круга специалистов; в формате XLS удобно представлять списки материалов; форматы SLDPRT и GT позволяют подключить к выполнению проекта конструкторов и технологов без установки на их рабочих местах дорогостоящих полнофункциональных лицензий CAD/CAE/CAM.

Оптимизация проекта — актуальные направления развития

Оптимизация изделия и производства на стадии проектирования является ключевой задачей для разработчиков программного обеспечения CAD/CAE/CAM/PLM. Чем раньше запускаются алгоритмы оптимизации в ходе проектирования, тем меньший объем неизбежных изменений приходится выполнять до выпуска изделия. В первую очередь оптимизация необходима на стадии расчетного обоснования проекта, где традиционно выполнялся только проверочный расчет, подтверждающий и согласующий конструкторское решение [2, 4].

Компания Autodesk предлагает новую идеологию оптимизации проекта, учитывающую на этапе CAD/CAE возможные варианты исполнения изделия (будущее видение изготовления — Future making seen). Важным элементом включения расчетчика в работу на ранних стадиях конструирования является топологическая оптимизация геометрии, которая позволяет изъять все фрагменты объема, не участвующие в обеспечении прочности. В результате такой оптимизации облегченная конструкция с заданной несущей способностью приобретает причудливую форму, изготовить которую проще всего с привлечением современных аддитивных технологий [18]. 

Авторитетный разработчик программного обеспечения для инженерного анализа CAE ANSYS [19] анонсирует развитие идеологии SDPD (Simulation Driving Product Development), которая усиливает роль компьютерной симуляции в конструировании и совершенствовании изделия. Подразумевается, что расчетчик включается в проверку изделия с начальной стадии конструирования и работает совместно с конструктором, совершенствуя модель в нескольких циклах «расчет — исправление геометрии». При таком подходе геометрия в каждом цикле перестраивается по результатам последней компьютерной симуляции, и расчет становится ведущим звеном по отношению к геометрическому моделированию.

Иной смысл вкладывает разработчик интегрированной системы CAD/CAE/CAM/PLM Siemens в аббревиатуру SDPD (System Driving Product Development), делая акцент на системный подход к требованиям. Оптимизация проекта осуществляется через управление требованиями к изделию. Требования к изделию и средства контроля за выполнением этих требований формулируются на старте и могут быть представлены V­образной структурой, где одновременно и послойно формируются требования (на спаде V­структуры) и тесты для их проверки (на подъеме V­структуры). В вершине V­структуры расположены общие требования к изделию, которые далее в слоях разбиваются на требования к функциональным подсистемам (система перемещения, схват, тормозная система, система подачи топлива, система кондиционирования и т.п.), узлам, деталям. Структура надстраивается по мере развития проекта, поскольку требования дополняются и усложняются. Например, после разработки и расчетного обоснования кинематики движений формируются требования к приводу. Соответствующие требованиям тесты для их проверки могут быть экспериментальными или осуществляться с использованием компьютерных программ в виде симуляций.

Обоснование использованного программного обеспечения и методики проектирования

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

Структурирование проекта и управление данными построено в среде Teamcenter с применением технологий PMI и SDPD. Отличительной особенностью проектирования в выбранной линейке программных продуктов является компонентный принцип 4th Generation Design (4GD), который позволяет оперативно обрабатывать экстремально большие сборки, составленные из сотен тысяч деталей.

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

Результаты проектирования робота­манипулятора в облаке

С использованием облачных технологий в среде Siemens Teamcenter был спроектирован робот­манипулятор как мехатронное изделие (рис. 1), полная структура которого разворачивается от механической подсистемы и включает другие важные подсистемы: электромеханическую, электронную, электрическую, сенсорную, энергетическую, программную.

Рис. 1. Объемная модель спроектированного робота-манипулятора в среде управления данными Siemens Teamcenter

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

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

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

Рис. 2. Конструкторская проработка электромеханической, электрической и электронной подсистем робота-манипулятора в среде Siemens Teamcenter (блок управления)

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

Описанная в статье методология системного проектирования мехатронного устройства в облаке показала хорошие результаты при апробации в УРФУ. Данная методика была реализована с помощью специалистов ГК «ПЛМ Урал», интегратора CAD/CAE/CAM/PLM-решений и золотого партнера компании Siemens PLM Software. Специалисты ГК «ПЛМ Урал» готовы дать консультации по вопросам внедрения методологии в учебный процесс вашего вуза. Обращаться для обсуждения можно по электронной почте info@plm-ural.ru или через сайт www.plm-ural.ru.

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

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

Выводы

Разработана и апробирована методология системного проектирования мехатронного устройства в облаке, которая может быть использована в промышленных или учебных целях, позволяя, в частности, имитировать разработку конструкции изделия в рамках концепции «домашнего проектирования». На сервере ЦОД УрФУ создана структура проекта робота­манипулятора в программной среде Siemens Teamcenter, которая позволяет развивать и варьировать содержание, а также наполнять новыми данными библиотеку присоединяемых схватов.

Список литературы:

1. Nolan D.C., Tierney C.M., Armstrong C.G., Robinson T.T. Defining Simulation Intent // Computer­Aided Design. 2015. V. 59. P. 50­63.
2. Огородникова О.М. Исследовательская функция программ CAE в сквозных технологиях CAD/CAE/CAM // Вестник машиностроения. 2012. № 1. С. 25­31.
3. Riesenfeld R.F., Haimes R., Cohen E. Initiating a CAD renaissance: Multidisciplinary analysis driven design Framework for a new generation of advanced computational design, engineering and manufacturing environments // Computer Methods, Applied Mechanics and Engineering. 2015. V. 284. P. 1054­1072.
4. Огородникова О.М. Методы и инструменты цифрового машиностроения для компьютерного моделирования технологий и конструкций // Научное обозрение. 2015. № 10­1. С. 209­212.
5. Mas F., Arista R., Oliva M., Hiebert B., Gilkerson I., Rios J. A review of PLM impact on US and EU Aerospace Industry // Procedia Engineering. 2015. V. 132. P. 1053­1060.
6. Огородникова О.М., Проничев И.М. Об опыте проектирования робототехнического комплекса для неразрушающего контроля // Проблемы машиностроения и автоматизации. 2016. № 3. С. 36­40.
7. Чижов М.И., Бредихин А.В., Хаустова Т.О., Гирчев Н.А. Автоматизация внесения архива конструкторско­технологической документации в PLM­систему TEAMCENTER // Вестник Воронежского государственного технического университета. 2011. Т. 7, № 12­2. С.15­17.
8. Zheng C., Duigou J. L., Bricogne M., Eynard B. Multidisciplinary interface model for design of mechatronic systems // Computers in Industry. 2016. V. 76. P. 24­37.
9. Огородникова О.М. О проблемах интеграции вычислительного материаловедения в цифровое машиностроение // Информационные технологии в проектировании и производстве. 2014. № 2 (154). С. 30­34.
10. Огородникова О.М., Ваганов К.А., Мушников Н.С., Юшков И.В. Адаптация стандартов ЕСКД последней редакции для проектирования промышленных роботов в интегрированной программной среде // Проблемы машиностроения и автоматизации. 2015. № 2. С. 49­55.
11. Огородников А.И., Власов В.Н., Огородникова О.М. Компьютерная оценка ожидаемого качества в системе управления технологическими процессами механической обработки // Проблемы машиностроения и автоматизации. 2015. № 1. С. 123­127.
12. David M., Rowe F. What does PLMS (product lifecycle management systems) manage: Data or documents? Complementarity and contingency for SMEs // Computers in Industry. 2016. V. 75.
    P. 140­150.
13. Whyte J., Stasis A., Lindkvist C. Managing change in the delivery of complex projects: Configuration management, asset information and ‘big data’ // International Journal of Project Management. 2016. V. 34. P. 339­351.
14. Хамьянов А.Ю. SSJ100: опыт территориально­распределенного проектирования воздушного судна в цифровом виде в условиях сложной кооперации // Rational  Enterprise Management. 2015. № 4. С. 38­41.
15. Wu D., Terpenny J., Gentzsch W. Cloud­Based Design, Engineering Analysis, and Manufacturing: A Cost­Benefit Analysis // Procedia Manufacturing. 2015. V. 1. P. 64­76.
16. Изменение условий бессрочного лицензирования. Сайт компании Autodesk. Адрес доступа к источнику информации свободный: http://www.autodesk.ru/products/perpetual­licenses/perpetual­licenses­faq. Время обращения к источнику информации: 07.04.2017.
17. Proctor F.M., Hoorn G., Lipman R. Automating robot planning using product and manufacturing information // Procedia CIRP. 2016. V. 43. P. 208­213.
18. Spalt P., Bauernhansl T. A Framework for integration of additive manufacturing technologies in production networks // Procedia CIRP. 2016. V. 57. P. 716­721.
19. Огородникова О.М. Конструкционный анализ в среде ANSYS. Екатеринбург: Изд­во УрФУ, 2004. 68 с.