Процесс разработки конструкторского состава двигателя, безусловно, один из самых важных этапов в процессе создания новых авиационных изделий. До недавних пор процедуры разработки и изменения изделий велись в основном в бумажном варианте. Однако организация данного процесса с использованием соответствующих программных средств, например, PLM-систем, позволяет ускорить как этап проектирования и выпуска электронной конструкторской документации (ЭКД), так и этап её технологической проработки и согласования на заводе-изготовителе [1, 4, 5].
Множество предприятий (например, ОАО «Авиадвигатель», ОАО «Московский вертолетный завод им. М.Л. Миля», АО «Воткинский завод» и др.) на текущий момент активно внедряют и развивают процедуры проектирования и согласования продукции в электронном формате, а электронная конструкторская документация (ЭКД) регламентирована [2] и принимается за самостоятельную подлинную документацию.
Стоит отметить, что для ведения ЭКД необходимо обеспечить полноту, достоверность и сохранность документации во время процедуры ее приема-передачи посредством сетевых технологий. Следует начинать с формирования полного комплекта документов и наполненности всех атрибутивных свойств. При несоблюдении этих требований в PLM-системе между объектами ЭКД могут нарушаться электронные связи, что увеличит сроки согласования из-за отсутствия важной для производственных подразделений информации.
Перечисленные ошибки и неточности в передаваемой ЭКД вызывают потребность повышения уровня автоматизации при работе с документацией на крупных машиностроительных предприятиях [6]. Внедрение дополнительных алгоритмических проверок на правильность заполнения атрибутивной информации (по возможности для каждого предприятия, участвующего в процессе приема-передачи) позволяет решить эту задачу для большого объема поступающей документации. Отдельно следует отметить, что относительная молодость процедур ведения ЭКД, специфика различных производств и требований к разработке, уникальных на каждом предприятии, делают практически невозможной или очень трудоемкой реализацию универсального механизма проверки документации в PLM-системах.
Постановка цели и задач
Корпорация АО «ОДК» состоит из одиннадцати двигателестроительных компаний, распределенных территориально. Каждое предприятие имеет свой исторически сложившийся процесс создания и сопровождения конструкторской документации. Каждое предприятие применяет различное программное обеспечение для решения задач производства. Совокупность непростых механизмов передачи ЭКД, отсутствие тесного взаимодействия и синхронизации проводимых работ при организации изменений является одной из причин, почему ни одна автоматизированная среда не позволяет создавать на предприятии качественную ЭКД без соответствующей настройки и адаптации.
Функция передачи-приема ЭКД на АО «ОДК-ПМ» возложена на несколько администраторов обмена данными (АОД). Дополнительными факторами, увеличивающими трудоемкость выполнения функций администраторов, являются: сложность некоторых технических аспектов, просмотр большого количества атрибутивной информации с определенными правилами и условиями ее обработки, проверка на комплектность документации, проверка наличия электронных графических моделей (ЭГМ), целостность электронной структуры изделия (ЭСИ) и т.д. Помимо всего, АОД ответственны за учет поступившей ЭКД, запуск процессов согласования и рассылку конструкторской документации по производственным подразделениям.
Целью и задачами данной работы является создание механизмов автоматизации процесса проверки, учета и регистрации ЭКД в соответствии с установленными на предприятии требованиями посредством разработки программного обеспечения, расширяющего базовые функции PLM-системы.
Общее описание процесса проверки ЭКД
Общая схема движения ЭКД представлена на рис. 1.
Рис. 1. Схема движения документации в методологии IDEF0
Рис. 2. Алгоритм работы при приеме и обработке ЭКД
При получении ЭКД от предприятия-разработчика АОД производит автоматическую и визуальную проверку. Визуально проверяют наличие в системе Teamcenter АО «ОДК-ПМ» всех позиций, указанных в описи сопроводительного письма. При отсутствии хотя бы одной позиции специалист оповещает об этом предприятие-разработчика по электронной почте с указанием всех отсутствующих позиций. Работа по всем позициям из описи приостанавливается до получения полного комплекта ЭКД.
Автоматическая проверка ЭКД проходит в несколько последовательных этапов:
– проверка на комплектность;
– проверка атрибутивной части;
– проверка содержательной части.
По завершению всех этапов проверки формируется запись в электронном журнале регистрации ЭКД с указанием результатов проверки. Детальный алгоритм приема и обработки документации администратором обмена данных приведен на рис. 2.
В результате проверки документации могут быть присвоены следующие статусы:
– «Без замечаний»: ЭКД соответствует требованиям условий проверок и доступно для отправки специалистом по указанному бизнес-процессу. Администратору обмена данными предприятия-разработчика, направившего ЭКД, автоматически направляется уведомление по электронной почте о принятии ЭКД. В журнале регистрации формируется запись «Без замечаний», для утвержденной КД формируются учётные карточки;
– «Допустимые замечания»: замечания, при которых ЭКД доступно для работы и направляется специалистом автоматически по указанному бизнес-процессу. Ответственному специалисту за конструкторскую документацию на АО «ОДК-ПМ» и администратору обмена данными предприятия-разработчика, направившего ЭКД, автоматически направляется уведомление по электронной почте о принятии ЭКД с указанием списка замечаний. Ответственный специалист проводит анализ замечаний и взаимодействует с ведущим отделом разработчика по их устранению. В журнале регистрации формируется запись «Допустимые замечания», для утвержденной КД формируется учётная карточка
– «Недопустимые замечания»: замечания, при которых ЭКД не доступна для дальнейшей работы специалистов АО «ОДК-ПМ». Администратору обмена данными предприятия-разработчика, направившего ЭКД, автоматически направляется уведомление по электронной почте о непринятии ЭКД с перечнем ошибок. До устранения замечаний, ЭКД не направляется по бизнес-процессам согласования, не формируется учётная карточка. В журнал регистрации при этом формируется запись «Недопустимые замечания» с их перечнем.
Проверка на комплектность включает в себя следующие пункты:
– сборочный чертёж и спецификация обязательно направляются в составе одного пакета;
– нормализованные ДСЕ обязательно направляются в составе одного пакета с модификацией электронной графической модели или шаблоном семейства (модификацией объекта с аналогичным шифром и суффиксом «.90» и «.mf» соответственно);
– бесчертёжный объект обязательно направляется в составе одного пакета совместно со спецификацией и сборочным чертежом, в состав которых он входит.
– групповые детали направляются в составе одного пакета с шаблоном семейства (объект с аналогичным шифром и суффиксом «.mf»);
– текущий комплект для серийного производства передаётся по Акту передачи, утверждённым разработчиком, изготовителем, представителями заказчика при разработчике и изготовителе согласно [3], а в атрибутивной карточке должно быть указание о литере серийного производства не ниже О1 и статус текущего комплекта;
– контрольный комплект передаётся пакетом по Акту приёма-передачи с приложенной описью.
Если пакет ЭКД не соответствует перечисленным требованиям, то результат проверки принимает значение «Недопустимые значения».
Вторая часть – проверка наличия атрибутов. В них содержится востребованная информация по характеристикам КД: масса и материал изготавливаемых деталей, формат чертежей или отметка бесчертежности, первичная применяемость детали (в сборочной единице), причина и содержание изменений у извещений на изменение, литера для контрольного или текущего пакета документации.
Рис. 3. Визуальное представление пользовательского интерфейса
Проверка содержательной части КД принимает значение «Без замечаний» при соблюдении следующих условий:
– наличие представления электронного чертежа, спецификаций в формате pdf;
– полная электронная структура изделия: наличие всех составляющих дсе на верхнем и остальных уровнях раскрытия сборочной единицы;
– наличие электронной графической модели и электронного чертежа (если не оформляется комплект без чертежа);
– для элементов типа «прочее» наборов данных типа «электронные чертежи», «эскизы», «ту», «паспорт»;
– для извещений на изменение – pdf-представление содержания извещения, таблицы изменения структуры для сборочных единиц в виде набора данных форматаxml, приложенные изделия хотя бы по одной связи«Утвердить» или «Аннулировать».
Все вышеописанные критерии и условия – не весь список проверки ЭКД на соответствие выставленным требованиям. Однако даже выполнение описанных действий визуально – кропотливая и трудоемкая работа. Разработанное программное обеспечение автоматизирует большую часть работ АОД в системе Teamcenter. Проверка множества объектов на полноту и корректность атрибутов заложена в процедуры обработки нажатия кнопок интерфейса, что снижает вероятность ошибки при визуальном контроле, а проработка сборочной единицы из сотни объектов занимает всего несколько минут. Вид интерфейса представлен на рис. 3.
Заключение
Результатом выполнения поставленных задач по автоматизации процессов проверки, учета и регистрации ЭКД служат разработанные: алгоритмы проверки документации; требования к обязательному содержанию документации; пользовательский интерфейс работы администраторов обмена данными в системе Teamcenter.
Предложенные механизмы автоматизации позволяют снизить трудоемкость на обработку ЭКД, повысить качество проверки документации и исполнять функции запуска электронных процессов в PLM-системе без участия администраторов обмена данными.