АВТОМАТИЗАЦИЯ КОНТРОЛЯ ВАЛИДНОСТИ КОНСТРУКТОРСКОЙ ДОКУМЕНТАЦИИ НА МАШИНОСТРОИТЕЛЬНОМ ПРЕДПРИЯТИИ

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

Одной из таких технологий является автоматизированная система, позволяющая автоматизировать различные процессы на предприятии.

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

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

Так, в данной статье рассматривается автоматизированная информационная система контроля валидности электронной конструкторской документации, разработанная на базе программных продуктов NX и Teamcenter компании Siemens, на ПАО «ОДК-УМПО» г.Уфа.

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

Программный пакет NX представляет собой одну из самых популярных систем автоматизации задач разработки и производства изделий, используемой практически во всех отраслях промышленности. Как любая система САПР верхнего уровня, NX сочетает в себе функционал для решения задач конструирования и проектирования (CAD), инженерного анализа (CAE) и подготовки производства (CAM). [3]

Интеграция системы Teamcenter c различными инструментальными платформами – это механические CAD, электрические и электронные CAD, системы анализа CAE и инструментальные средства офисного документооборота (Microsoft Office, Microsoft Exchange, Microsoft Explorer и SharePoint и т. д.), обеспечивает полное электронное описание изделия, управляемое из единой среды Teamcenter. Teamcenter – платформа для разнородных приложений (так называемая multi-CAD- платформа), которая интегрирована не только с приложениями от Siemens PLM Software в области проектирования и анализа, но и с другими продуктами, предоставляющими средства проектирования изделий машиностроения, приборостроения, строительства и т. п. Это продукты Autodesk, Dassault Systems, PTC, ECAD-системы – Mentor, Cadence, Synopsys и др. [4]

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

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

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

Мнемосхема существующего процесса приведена на рис.1

Рисунок 1. Мнемосхема процесса утверждения КД

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

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

Следующим этапом анализа существующего бизнес-процесса является построение функциональной модели, которая позволит выявить уязвимые места деятельности организации.

Кроме того, она отражает функциональное содержание рассматриваемого процесса, является структурированным изображением функций процесса, связей между ними и со средой семантики, отражающей эти функции [5]

В качестве инструмента для построения функциональной модели выбрано CASE–средство BPWin, которое поддерживает методологию IDEF0

Рисунок 2. Контекстная диаграмма

Рисунок 3. Функциональная модель существующего процесса

На рис. 4 отображена декомпозиция блока «Провести вторичную проверку», в рамках которого проектируется АИС, позволяющая проводить вторичную проверку в отделе стандартизации и сертификации автоматически:

Рисунок 4. Декомпозиция блока «Провести вторичную проверку»

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

Необходимость избавления от бумажного документооборота стала следствием увеличения объема обрабатываемых данных и переходом на новые стандарты предприятия. Внедрение АИС, способствующее переходу на электронную документацию, потребовало новый подход как к отдельным операциям, так и к бизнес-процессу в целом.

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

Ниже представлена мнемосхема предлагаемого процесса с учетом выявленных проблем и предлагаемых путей их решения (рисунок 6).

Одним из отличий с существующим процессом является то, что в предлагаемом все замечания и исправления будут храниться БД Teamcenter (TCE):

Рисунок 5. Мнемосхема предлагаемого процесса

Функциональная модель после внесения изменений представлена на рисунке 6;

Декомпозиция функционального блока «Утвердить графическую ЭКД в ОКБ» представлена на рисунке 7;

Декомпозиция функционального блока «Пройти вторичную проверку» представлена на рисунке 8.

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

Рисунок 7. Декомпозиция функционального блока «Утвердить графическую ЭКД в ОКБ»

Рисунок 8. Декомпозиция функционального блока «Пройти вторичную проверку»

В функциональной модели предлагаемого процесса АИС занимается хранением ЭКД, замечаний, поступающих отделов, списки исправлений и проведенных проверок.

В предлагаемом бизнес-процессе все отделы посылают служебную информацию в АИС для ее последующего использования отделами проектирования.

Так, отделы проектирования и прочности проходят этапы согласования, в результате которого отправляют разработанную модель и чертеж в БД TCE. Затем инженер по стандартизации проводит первичную проверку и ее результаты посылает в БД TCE. Исходя из результатов первичной проверки ЭКД будет рассмотрена ОГТ, в том случае если ошибок нет, или вернется на рассмотрение в отдел проектирования со списком замечаний, если инженер по стандартизации обнаружил ошибки.

Затем после проверки главным технологом и согласования с бюро нормирования материалов ЭКД посылается в БД TCE для дальнейших проверок ОГМет. Документ проходит этап согласования с бюро покрытий и бюро штамповок, в результате чего посылается в БД TCE для проверки ведущим конструктором и т.д.

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

Таким образом, эта концепция позволяет достичь автоматизации процесса, о которой было заявлено ранее.

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

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

1. А. И. Арзамазов «РОЛЬ ИНФОРМАЦИИ В РАЗВИТИИ СОВРЕМЕННОГО ПРЕДПРИНИМАТЕЛЬСТВА»  - 2012г. – 10стр.
2. Автоматизированные информационные системы : учебник для студ. учреждений сред. проф. образования / К.Н.Мезенцев. — 4-е изд., стер. — М. : Издательский центр «Академия», 2013. — 176 с.
3. Данилов Ю., Артамонов И. Д17 Практическое использование NX. – М.: ДМК Пресс, 2011. – 332 с.: ил
4. Тороп Д. Н., Терликов В. В. T61 Teamcenter. Начало работы – М.: ДМК Пресс, 2011. – 280 с.: ил
5. Д.Э. Федотова, Ю.Д. Семенов «CASE-технологии. Практикум», 2005г. – 160 стр