Интегрированная система создания электронной модели авиационной сборочной оснастки Текст научной статьи по специальности «Компьютерные и информационные науки»

УДК 658.27; 658.52.011.56

ИНТЕГРИРОВАННАЯ СИСТЕМА СОЗДАНИЯ ЭЛЕКТРОННОЙ МОДЕЛИ АВИАЦИОННОЙ СБОРОЧНОЙ ОСНАСТКИ

© 2014 П.Е. Чимитов, М.В. Лаврентьева

Иркутский государственный технический университет

Поступила в редакцию 08.09.2014

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

Ключевые слова: сборочная оснастка, автоматизация, программный комплекс, САПР, самолетостроение, электронная модель

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

• высокие требования к качеству самолета, прежде всего по характеристикам прочности и надежности;

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

• исключительная многодетальность конструкции планера самолета, обуславливающая значительную трудоемкость непосредственно сборочных работ;

• относительно частая смена объекта производства, зачастую требующая практически полного пересмотра производства.

Чимитов Павел Евгеньевич, кандидат технических наук, доцент кафедры самолётостроения и эксплуатации авиационной техники. E-mail: pro-teus1982@mail.ru

Лаврентьева Мария Вячеславовна, аспирантка. Email: mira.amazon@gmail.com

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

Основной особенностью непосредственно самолетостроения является высокий удельный вес сборочных работ в трудоемкости изготовления самолета [1], которая может достигать 50%. Кроме того, использование специфических методов базирования (базирования от базовых поверхностей) определяет большой объем сборочной и вспомогательной оснастки, значительный объем работ (сборка, базирование, фиксация, расфиксация, переналадка оснастки и т.д.) и повышает значимость непосредственно этапа сборки для достижения заданных параметров точности (итоговая точность самолета в итоге в значительной степени формируется на этапах сборки).

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

1640

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

Цель работы: автоматизация конструк-торско-технологической подготовки сборочного производства (создание САПР, ориентированной на проектирование авиационной сборочной оснастки).

Выбор данного этапа сборки был обусловлен рядом причин. До недавнего времени автоматизации непосредственно работы конструктора (принятие решений, выбор компоновки, экспертные оценки и т.д.) уделялось достаточно мало внимания, в отличие от автоматизации производственных процессов [2, 3, 6]. Кроме того, значительная часть используемых в самолетостроении САПР являются изначально общемашиностроительными и не ориентированы на решение специфических узкоспециальных задач, связанных с проектированием сборочной оснастки (хотя общий ее объем значителен и, как следствие, высока трудоемкость и затраты ресурсов на проектирование). При создании подобной САПР (либо на первом этапе создание программных модулей в составе базовой САПР) нежелательно создавать еще одно сугубо инструментальное средство т.к. при этом всегда сохраняется возможность допустить ошибку при выполнении проектных работ с ее использованием (человеческий фактор). Таким образом, наиболее оптимальным решением выглядит создание не просто новых инструментальных средств моделирования, а модулей, позволяющих типизировать решения, отслеживать (не допускать) критических ошибок, т.е. создание интеллектуальной системы поддержки принятия решений. Данный подход более сложен, однако в перспективе может дать больший эффект.

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

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

Для повышения эффективности технологической подготовки сборочного производства выполняется разработка и внедрение «подсистемы поддержки принятия решений в системе автоматизированного проектирования объектов сборочного производства». Использование предлагаемой системы позволит снизить трудоемкость, повысить качество принимаемых решений, а так же сократить общий цикл проектирования сборочной оснастки. В силу того, что профильным подразделением заказчика является отдел, выполняющий непосредственно рабочее проектирование конструкции сборочного приспособления (СП), а также с учетом существующей на предприятии информационной инфраструктуры, разрабатываемая система направлена на автоматизацию этапов проектирования СП, связанных с построением ЭМ конструкции СП в среде САПР Siemens NX. По итогам проведенного в рамках работы анализа конструкции СТО и принятой методики его проектирования были выработаны следующие принципы, используемые при разработке программных модулей системы.

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

1641

Для обеспечения преемственности при создании ЭМ конструктором и программной системой принято решение, согласно которому создаваемый ЭМ должен быть максимально близок к ЭМ, созданным традиционным способом (для возможности дальнейшего редактирования). К числу основных критериев можно отнести:

• использование объектов теоретического электронного макета (ТЭМ) для первоначальной привязки ЭМ СТО в пространстве изделия;

• соблюдение всех требований, предъявляемых к ЭМ на предприятии (точность моделирование, параметризация, предпочтительные операции построения, разбивка по слоям и т.д.).

При непосредственной работе по созданию программных модулей системы и системы в целом использованы следующие архитектурные решения. Каждый программный класс, отвечающий за построение модели конкретного объекта СТО, состоит из двух частей. В первой из них (class) создаются все основные методы, необходимые для описания и увязки создаваемого компонента СТО как объекта в памяти системы (виртуальный компонент, увязанный с виртуальными компонентами СТО). Во второй - сосредоточены исключительно методы, необходимые для построения ЭМ созданного объекта СТО в среде САПР Siemens NX. Использование двухкомпонентного подхода к построению метода (основной класс Class и класс билдера Class.Builder) позволяет в перспективе путем замены классов реализации (Class.Builder), использующих API САПР, переориентировать программные модули на построение ЭМ объекта в среде другой САПР. Например, созданный объект рама (содержащей основные данные о типе проката, габаритах, форме, родительских и дочерних компонентов и т.д.) можно реализовать средствами NX Open API в виде твердотельной ЭМ в среде Siemens NX, либо используя открытый программный интерфейс Autodesk AutoCAD в виде плоского чертежа. Принципиально данный подход позволяет значительно расширить область применения системы, однако накладывает дополнительные требования к созданию программных классов (рис. 1).

Кроме выделения типовых процедур построения элементов СТО в общие программные классы (на основе проведенного анализа и классификации объектов), рационально также выделение в самостоятельные блоки общих служебных функций системы (такие как подключение к БД, интерфейс, подключение к др). Наличие в системе классов, отвечающих за общую компоновку СТО (увязка параметров), классов наблюдателей (отслеживание изменений параметров)

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

Данные об о6ъ«гте

проектирования

1 1

Oass

(Подготовка контекста построений)

Class Builder (AutoCAD API)

Рис. 1. Реализация двухкомпонентного подхода при создании класса

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

Создание любой сложной программной системы включает в себя анализ доступных и наиболее рациональных средств разработки. Кроме того, при их выборе необходимо учитывать ряд ограничений, накладываемых исходным техническим заданием и существующими на данный момент производственными условиями на предприятии. Ввиду того что разрабатываемая система является частью САПР Siemens NX

1642

(т.к. это основная среда разработки геометрической информации на ИАЗ), то был выполнен анализ доступных средств автоматизации базовой САПР, а также перечень требований и ограничений, накладываемых его открытым программным интерфейсом (NX Open API), посредством которого создаются различные модули расширения функциональности. В результате были выбраны и использованы следующие инструментальные средства и подходы к созданию программного модуля. Основной язык программирования C++ и среда разработки Microsoft Visual Studio 2008 были использованы, т.к. это рекомендовано при работе с NXOpen API. В качестве дополнительных библиотек были использованы совместимые с C++. К их числу относятся Qt [4] и Eigen [5], позволяющие значительно сэкономить ресурсы при разработке программных модулей (использование заранее созданных шаблонов и библиотек для наиболее рутинных и общих операций). Использование в качестве СУБД системы продукции компании Oracle про-

диктовано существующей информационной инфраструктурой предприятия заказчика.

Проведенный анализ доступных средств NX позволил выделить следующие компоненты САПР, наиболее рациональных при разработке системы:

• сборка (концепция мастер - модели);

• UDF;

• KF;

• Expression (выражения);

• семейства деталей (part family).

Использование этих компонентов NX позволило сформировать три основных подхода (логики работы программных модулей) при создании ЭМ. Следует отличать архитектуру системы в целом (описанную выше) от логики работы (структуры) конкретного программного модуля или метода, комбинирующего различные доступные средства для достижения поставленной цели [9] (рис. 2).

Рис. 2. Диаграмма последовательности работы программного модуля

Все ЭМ стандартных элементов СТО (не изменяемые при использовании на различных СП - нормали, типовые прижимы и фиксаторы и т.д.) добавляются в ЭМ сборки без изменений. При этом для всего множества стандартных элементов возможно использование одного программного модуля (stdPartBшlder на рис. 2), основная задача которого - задание необходимой ориентации и координат в пространстве ЭМ сборочного приспособления. Структурно

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

1643

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

Создание элементов посредством использования «прототипов». В данном контексте под «прототипом» понимается заранее созданная ЭМ элемента СП, модифицируемая в процессе обработки программным модулем (CloneBuilder на рис. 2). В отличие от предыдущей схемы данная логика работы программного модуля подразумевает кроме задания координат и ориентации компоненту, также изменения каких-либо геометрических параметров. Принципиальным отличием от предыдущей схемы является то, что файл ЭМ физически копируется в директорию проекта (либо в любую другую директорию по желанию конструктора), которому присваивается уникальное имя в рамках ЭМ сборки. В первом варианте физического копирования ЭМ не происходит, а передается исключительно ссылка на компонент (концепция «мастер-модели»). Как и в первом варианте, обработку всех элементов-прототипов осуществляет только один программный модуль (CloneBuilder), для корректной работы которого потребуется заранее создать множество элементов и подготовить в СУБД для них соответствующие записи. Дополнительным требованием является корректное задание геометрических параметров и их связей у КЭМ прототипа (типовые имена, идентичные переменные и т.д.), посредством модуля expressions (выражения) САПР Siemens NX (рис. 2)

Третий вариант построения является наиболее гибким, но при этом наиболее трудоемким с точки зрения создания программного кода. Сущность его заключается в формировании ЭМ элемента СТО исключительно программным кодом с использованием доступных функций NXOpen API (рис. 2). В отличие от первых двух вариантов в этом случае не требуется предварительное создание каких-либо ЭМ. Для каждого элемента СТО необходимо создание своего программного класса (ElementBuilder на рис. 2). В значительной степени снизить трудоемкость в этом случае позволяет выполненная ранее классификация и использование подходов объектно-ориентированного программирования (наследование). При создании множества классов данного типа предъявляют определённые требования и к разработчику программного кода, который должен кроме навыков программирования, так

же обладать навыками работы в САПР (моделирование). Для снижения трудоемкости создания множества классов данного типа рационально использование сторонних библиотек (qt, eigen) и автоматизированных средств самой САПР (UDF, KF, семейства деталей). Наиболее яркий и показательный пример эффективности использования такого подхода можно проиллюстрировать на примере построения рамы СП.

Использование стандартных элементов и прототипов для рамы (а также для рубильников и ложементов) ограничивается рядом причин:

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

• разнотипные варианты исполнения сечения (квадрат, швеллер, тавр, двойной швеллер и т.д.),

• необходимость получения «элементов построения» (features), а не множества «компонентов сборки».

Процедура (метод) построения с использованием средств автоматизации закладывается в структуру программного модуля построения рамы. При этом общая логика работы программного модуля будет следующей. Запрос у пользователя основных габаритных размеров рамы и ее конфигурация, привязка рамы к СК самолета, запрос необходимых для обработки UDF параметров (размеры сечения, тип сечения), построения эскиза рамы (образующие), построение сечения (проката) рамы средствами UDF. Кроме оптимизации процесса создания кода данный подход снижает трудоемкость подготовительных работ. В этом случае необходимо создание по одному файлу UDF (средствами NX) для каждого типа сечения рамы (швеллер, квадратная труба, двутавр) и, соответственно, по одной записи в СУБД на каждый типоразмер (либо, как будет описано далее, можно полностью отказаться от хранения данных в СУБД в пользу средств автоматизации NX). Единственным важным моментом при подготовке файлов UDF - соблюдение корректности и типизация ссылок и взаимосвязей внутри элемента [2, 3]. Использование таких средств NX как KF и «семейств деталей» можно дополнительно повысить удобство использования модуля и повысить его уровень автоматизации (кроме того, устранить возможность ошибки при задании размеров профиля). В этом случае связка правил KF - «семейства деталей» - UDF позволяет как пользователю, так и системе оперировать не множеством размеров сечения профиля, а только его номером (условным обозначением по ГОСТ. Несмотря на то, что на первый взгляд использование средств автоматизации NX при построении ЭМ исключительно программным кодом только усложняет

1644

процесс, это все же позволяет ввести некоторые изменения в организационную структуру работы над проектом. Это касается перераспределения трудоемкости между программистом и модели-ровщиком. В этом случае программист оперирует исключительно переменными (без значительной привязки к специфике самолётостроения и моделирования в среде ЫХ), такими как «номер профиля» (число). Моделировщик, используя исключительно средства ЫХ, может не обладать навыками программиста. Его основная цель -создание корректной ЭМ и подготовка семейства сечений (набор типоразмеров профиля) с привязкой к их номеру (номер проката или его условное обозначение). Даже если устранить какую-либо возможность ошибки при моделировании ЭМ, всегда остается шанс ошибки на этапах компоновки (т.к. за это отвечает человек). Как отмечалось ранее, для этого необходима формализация проектных процедур принятия решений. Развитие этого направления заключается в формализации проектных процедур, проработке логики решения задач компоновки, базирования и некоторых задач технологии сборки самолета. В общем случае разрабатываемые формальные процедуры должны после нажатия пользователем кнопки «старт» самостоятельно выполнить анализ конструкции агрегата, учесть его особенности производства, затем выполнить поиск наиболее оптимального варианта компоновки, выполнить поиск нормалей и выполнить окончательную увязку элементов конструкции СТО между собой. В качестве дополнительной функции выполнить анализ технологичности сборки как СТО, так и изделия в готовом приспособлении. Т.к. единовременно реализовать весь массив подобных процедур невозможно, в программных модулях системы необходимо предусмотреть возможность расширения инструментальной составляющей логическими, без существенной переработки кода системы.

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

• формализация структуры сборочной оснастки [10, 12];

• формализация построения последовательности сборки [11];

• формализация выбора сборочных баз [7, 8,].

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

Выводы: на сегодняшний момент в рамках работы выполнена проработка общей архитектуры системы, определены основные методики проектирования СТО и создания ЭМ. В создаваемой системе реализованы методы построения ЭМ СП для сборки панелей, узлов, ведутся работы по созданию программных методов построения вспомогательной и контрольной оснастки, а также расширение функционала существующих компонентов системы. Актуальность работы сохраняется даже в случае перевода всего производства на полный автоматизированный цикл [6], т.к. в любом случае остается достаточно большой объем работ по созданию вспомогательной оснастки, либо модернизации существующей под требования автоматизированной сборки. При сохранении общей структуры системы путем замены (модернизации) элементной базы, можно адаптировать систему под построения любой машиностроительной оснастки.

Работа выполняется в рамках договора №389/12 от 15.11.2012 г. «Автоматизация и повышение эффективности процессов изготовления и подготовки производства изделий авиатехники нового поколения на базе Научно-производственной корпорации «Иркут» с научным сопровождением иркутского государственного технического университета», дополнительное соглашение №12 «Разработка подсистемы поддержки принятия решений в системе автоматизированного проектирования объектов сборочного производства». Указанный договор заключён согласно постановлению Правительства Российской Федерации от 15 ноября 2012 г. №218, 3 очередь.

СПИСОК ЛИТЕРАТУРЫ:

1. Пекарш, А.И. Современные технологии агрегат-но-сборочного производства самолётов / А.И. Пекарш, Ю.М. Тарасов, Г.А. Кривов и др. - М.: Аграф-пресс, 2006. 304 с.

2. Официальный сайт Siemens PLM Software [электронный ресурс] - режим доступа. http://www.plm.automation.siemens.com/ru_ru/

3. Данилов, Ю. Практическое использование NX / Ю. Данилов, И. Артамонов. - М.: ДМК Пресс, 2011. 332 с.

4. Официальный сайт проекта Qt Project [Электронный ресурс] - Режим доступа: http://qt-project.org/

5. Официальный сайт проекта Eigen [Электронный ресурс] - Режим доступа: http://eigen.tuxfamily.org

6. Dürr AG official website [Электронный ресурс] -Режим доступа: - http://www.durr.com/

7. Ахатов, Р.Х. Выбор опорных базовых точек при определении схемы базирования сборочной единицы / Р.Х. Ахатов, Х.В. Чьен // Вестник Московского авиационного института. 2013. Т. 20, №3. С. 110118.

8. Ахатов, РХ. Определение степеней свободы элементов конструкции сборочной единицы / РХ. Ахатов, Х.В. Чьен // Вестник Иркутского государственного технического университета. 2013. №2. С. 57-62.

1645

9. Лаврентьева, М.В. Автоматизированное проектирование электронных макетов элементов сборочной оснастки посредствам программного модуля NX/Open API / М.В. Лаврентьева, Х.В. Чьен // Известия Самарского научного центра Российской академии наук. 2013. Т. 15, №6(2). С. 395-399.

10. Чьен, Х.В. Определение состава базирующих элементов сборочного приспособления при сборке авиационного изделия /Х.В. Чьен, М.В. Лаврентьева // Вестник Иркутского технического университета. 2013. №11. С.74-81.

11. Чимитов, П.Е. Построение последовательности сборки планера самолёта на основе образа изделия // Вестник Сибирского государственного аэрокосмического университета им. академика М.Ф. Ре-шетнева. 2009. №2 .С. 218-222.

12. Чимитов, П.Е. Концепция автоматизированного проектирования средств технологического оснащения сборочного производства // Вестник ИрГТУ. 2011. №12(59). С. 52-57.

THE INTEGRATED SYSTEM OF CREATION THE ELECTRONIC MODEL OF AVIATION ASSEMBLY EQUIPMENT

© 2014 P.E. Chimitov, M.V. Lavrentyeva

Irkutsk State Technical University

The developed system is the module of expansion the functionality for SAPR Siemens NX7.5, adding the new tools, directed on automation of design works of electronic models, assembly equipment applied in aircraft construction. The system is focused on optimization of design engineer work at design assembly equipment. The techniques put in systems are most approached to be applied at the enterprise. The general architecture of system is constructed taking into account possibility of expansion of its application area and saturation by formalized procedures for the purpose of bigger automation at design of assembly equipment.

Key words: assembly equipment, automation, program complex, SAPR, aircraft construction, electronic model

Pavel Chimitov, Candidate of Technical Sciences, Associate Professor at the Department of Aircraft Building Engineering and Exploitation of Aviation Equipment. E-mail: proteus1982@mail.ru

Maria Lavrentyeva, Post-graduate Student. E-mail: mira. amazon@gmail.com

1646