Разработка и внедрение системы управления инженерными данными ФГУП ММПП «Салют»
Спецификации со снятыми и вновь устанавливаемыми составными частями
Классификация и контроль применяемости стандартных изделий
В настоящей статье мы хотели бы рассказать об опыте внедрения современной системы управления инженерными данными на ФГУП ММПП «Салют».
Целью ее внедрения являлось повышение эффективности работы инженерных служб предприятия по ведению конструкторской и технологической документации в электронном виде, обеспечение электронного технического документооборота в рамках всего предприятия, формирование единого информационного пространства предприятия как платформы для корпоративной информационной системы.
На начальном этапе решался вопрос разработки собственной PDM-системы, которая бы учитывала все годами складывавшиеся специфические особенности ведения конструкторской документации на предприятии или приобретения уже готовой системы.
Системы собственной разработки, как правило, более адаптированы к бизнес-процессам предприятия. Однако создать силами собственных программистов систему, которая по возможностям была бы сравнима с хорошей PDM-системой, разрабатывавшейся на протяжении многих лет с учетом опыта внедрения и сопровождения на многих предприятиях, практически невозможно. Поэтому курс был взят на поиск и приобретение системы, которая бы наилучшим образом отвечала требованиям инженерных служб и могла служить платформой для системы управления предприятием.
На ФГУП ММПП «Салют» была сформирована группа из специалистов — представителей разных подразделений, которые провели сравнительный анализ имеющихся на рынке PDM-систем на соответствие требованиям предприятия. В итоге в качестве платформы для создания системы управления инженерными данными «Салют» была выбрана система Omega Production фирмы OmegaSoftware.
По результатам обследования инженерных служб предприятия был составлен план адаптации и внедрения системы. Специалистами предприятия совместно с представителями фирмы-разработчика были определены жизненные циклы для всех типов электронных документов, а также правила поведения документации на каждом из статусов жизненного цикла. После конвертации имевшиеся электронные данные по составам изделий, маршрутам и материальным нормативам были переданы соответствующим подразделениям-владельцам для их выверки и преобразования в полноценные электронные документы.
В настоящее время вся электронная конструкторская документация по изделиям, разрабатываемым и производимым предприятием, находится в системе. Она поддерживается в актуальном состоянии через электронные конструкторские и технологические извещения об изменениях. Рассылка электронной документации по учетным пунктам хранения также производится в электронном виде в соответствии с шаблонами рассылки.
На основании данных о структуре и составе изделий, маршрутах и материальных нормативах выполняется расчет материальных затрат, потребностей в ресурсах для отдельных деталей, узлов, изделий и заказов, а также по планам производства.
Развитие задач системы для предприятия производится как фирмой-разработчиком, так и собственными программистами, которые работают в рамках единого проекта.
В данной статье мы рассмотрим несколько отдельных задач, характеризующих специфику данных и бизнес-процессов предприятия.
Сводные спецификации
До внедрения PDM «Салют» одним из основных типов документов, описывающих структуру и состав изделий при подготовке производства и в производстве, являлись сводные спецификации. Документы с такими наименованиями применяются на многих предприятиях. В нашем случае сводные спецификации определяют структуру и состав изделий по конструктивным группам. Сводные спецификации строятся на основе единичных, «узловых» спецификаций. Поэтому если рассматривать данные спецификации с документной точки зрения, то они являются не первичными, а производными документами. Производные структуры в электронном виде лучше всего получать в виде отчетов, а не электронных документов. Однако в процессе внедрения системы сразу определить сводные спецификации в качестве отчетов не удалось. Изменить сложившиеся процессы документооборота, пока еще не внедрены новые процессы, очень сложно. И дело тут даже не в человеческом факторе — неприятии нового, а в том, что внедрение происходит поэтапно и собственные документы используются в разных подразделениях завода. Те подразделения, где уже выполнено внедрение, не могут отказаться от старых документов, потому что они нужны другим подразделениям, а ведение одновременно и первичных и производных документов — это дополнительная нагрузка и источник ошибок. Для минимизации трудоемкости создания и ведения документации были разработаны функции автоматического создания и корректировки сводных спецификаций на основе узловых спецификаций и данных о принадлежности конструкторских элементов к конструктивным группам.
Только через два года после внедрения конструкторские и технологические службы предприятия смогли отказаться от сводных спецификаций в качестве электронных документов и перейти на получение в тех подразделениях, где это необходимо, сводных отчетов. Сводные отчеты получаются в той же структуре, что и сводные спецификации, на основе актуальных версий электронных узловых спецификаций. Примеры интерфейсов сводных спецификаций и сводных отчетов приведены на рис. 1.
Рис. 1. Сводная спецификация и сводный отчет
 |
|
Спецификации со снятыми и вновь устанавливаемыми составными частями
На предприятии большое количество узлов разрабатывается на основе других узлов, которые выступают в этом случае в качестве заготовок. Спецификации таких узлов конструкторам удобнее всего формировать в соответствии с ГОСТ 2.109-73, определив узел-заготовку, «снятые составные части» и «вновь устанавливаемые составные части». В системе был создан механизм ведения спецификаций с дополнительными секциями, причем некоторые из них являются предопределенными, но возможно создание и секций спецификаций с произвольными наименованиями. При удобстве и краткости написания спецификаций, определенных стандартом, система правильно рассчитывает состав узлов, созданных на основе заготовок, для целей планирования (рис. 2).
Рис. 2. Спецификация узла на основе узла-заготовки
|
|
Ремонтные спецификации
Одной из составляющих производственной программы предприятия является капитальный ремонт двигателей. В связи с этим актуальной является задача планирования материальных ресурсов, требуемых для ремонта.
Планирование ремонта строится на основе «ремонтных составов» изделий, которые формируются по ремонтным спецификациям узлов.
Ремонтные спецификации узлов определяют состав узлов изделия с точностью до деталей и сборок, которые должны быть заменены или восстановлены при ремонте. Количество заменяемых деталей и узлов определяется на основе данных об их ресурсе и статистических данных по производимым заменам. Восстанавливаемые детали имеют то же обозначение, что и новые, однако маршруты и технологические процессы данных деталей не совпадают с теми, что применяются при производстве новых деталей. Та же проблема и с ремонтными узлами, которые имеют обозначения, совпадающие с обозначениями соответствующих им оригинальных узлов, но при этом другой состав.
Выходом из данного затруднения явилось введение соответствующего типа данных «Ремонтные узлы» и ввод настроек, определяющих уникальность обозначений объектов одного типа с объектами других задаваемых типов. Пример ремонтной спецификации приведен на рис. 3.
Рис. 3. Ремонтная спецификация узла
|
|
Классификация и контроль применяемости стандартных изделий
Первичный ввод спецификаций изделий в систему производился на основе имеющихся электронных баз данных и конструкторского архива твердых копий документов. Поэтому при создании электронных составов изделий автоматически создавались и конструкторские элементы. При всех преимуществах данного подхода он приводит к тому, что для конструкторских элементов со сложными, длинными идентификаторами, к которым относятся и стандартные изделия, существует высокая вероятность записи одного и того же элемента под разными обозначениями. При этом функция поиска и контроля похожести элементов, применяемая в системе, только отчасти решает проблему. Поэтому перед конструкторским отделом стандартизации была поставлена задача проверки справочников стандартных и прочих изделий с целью исключения дублирования элементов, корректировки спецификаций изделий и создания классификаторов стандартных изделий для решения вопросов контроля применяемости и унификации.
Корректировка спецификаций проводилась с использованием имеющихся в системе функций поиска и контекстной замены конструкторских элементов. Для стандартных изделий с неправильными обозначениями после снятия с них применяемости появилась возможность аннулирования или удаления.
Пример классификатора стандартных изделий приведен на рис. 4.
Рис. 4. Классификатор стандартных изделий
|
|
Извещения об изменениях
Одним из основных элементов системы управления данными об изделиях являются электронные конструкторские извещения об изменениях, через которые выполняется автоматическое изменение электронных спецификаций изделий, а также выпуск новой электронной документации и аннулирование устаревшей.
Извещения об изменениях являются электронными документами-контейнерами, при продвижении которых происходит автоматическое продвижение конструкторских документов, включенных в извещение, в соответствии со статусом документации их жизненных циклов. Собственный жизненный цикл извещений об изменениях приведен на рис. 5. В соответствии со стандартом предприятия после проработки извещений об изменениях в подразделениях предприятия на техническом совете производится их принятие или аннулирование, что и реализовано в жизненном цикле извещений. Для аннулированных извещений определены правила управления конструкторскими элементами, включенными в извещения.
Рис. 5. Жизненный цикл извещений об изменениях
Для предприятия характерно большое количество «внешних» извещений, то есть извещений, инициированных внешними по отношению к предприятию разработчиками документации. В настоящее время такие извещения поступают на предприятие в виде твердых копий. При принятии внешних извещений также должно производиться изменение действующих электронных спецификаций изделий. Поэтому внешние извещения сканируются и на их основе создаются извещения системы, которые выполняют изменение документации. Сканированный образ внешнего извещения включается в электронные данные созданного электронного извещения и в его печатную форму.
Функциональность электронных извещений об изменениях полностью соответствует ГОСТ 2.503 и доработана для реализации групповых операций изменений конструкторских элементов в соответствии с действующим отраслевым стандартом. Это позволяет конструкторам, которые формируют и проводят извещения, работать с привычными для них бизнес-процессами, и в то же время с помощью извещений производится автоматическое изменение электронной конструкторской документации в электронном архиве и производственных копиях документов. После проведения электронные извещения об изменениях рассылаются с помощью встроенной электронной почты системы по учетным пунктам в подразделениях предприятия.
|
|
Ведомости маршрутов
В ведомостях маршрутов представляются данные о составе изделий и маршрутах движения конструкторских элементов с точностью до видов работ в подразделениях предприятия. Ведомости маршрутов являются наиболее используемыми документами в производственно-диспетчерских бюро цехов, технологических бюро и производственно-диспетчерском отделе предприятия.
В исходном варианте ведомости маршрутов являлись одним из основных технологических документов и, ввиду его ответственности, на предприятии было принято решение реализовывать ведомости маршрутов в системе как электронные документы, хотя это порождает трудности с поддержанием целостности данных и проведением изменений. Для удобства пользователей документы в системе создавались точно в таком виде, в каком они существовали в твердых копиях. Были разработаны редактор и бизнес-логика ведомостей маршрутов, а также их печатные формы. Однако уже на этом этапе были заложены основы для постепенного перехода от ведения технологических маршрутов в виде документов-ведомостей к более гибкому механизму ведения маршрутов как отдельных единиц технологической документации, не связанных жестко с каким-либо документом, включающим состав узлов или изделий. При первичном импорте ведомостей маршрутов из локальной системы, где они велись, создавались не только сами документы, но и заполнялась база данных самостоятельных технологических маршрутов.
Был также реализован электронный документ об изменениях ведомостей маршрутов — «Извещение об изменениях маршрутной технологии». Для проведения изменений использовался, как и для всех документов системы, универсальный ревизионный механизм.
Постепенно в режиме эксплуатации системы пользователям-технологам стали понятны преимущества ведения самостоятельных технологических маршрутов. В результате сложились предпосылки для отказа от неудобной и громоздкой системы ведения ведомостей маршрутов как электронных документов.
В настоящее время происходит переход от ведения ведомостей маршрутов к ведению собственно маршрутов. При этом ведомости маршрутов в привычной форме получаются как отчет на основе актуального конструкторского состава, поддерживаемого в электронном виде конструкторами, и маршрутов конструкторских элементов, разрабатываемых и сопровождаемых технологами.
Для реализации более гибкой системы изменений был осуществлен переход от громоздких «Извещений на изменение маршрутной технологии», где изменялись ведомости маршрутов, к более наглядным и легким в чтении/редактировании «Извещениям на изменение маршрутов», где вводятся, изменяются или аннулируются только сами маршруты конструкторских элементов с учетом данных об их входимости и применяемости, если маршрут зависит от применяемости.
Для обеспечения безболезненного перехода использовавшиеся ранее печатные формы были сохранены. Печатные формы разрабатываются с помощью имеющегося в системе редактора форм. Пример печатной формы ведомости маршрутов приведен на рис. 6.
Рис. 6. Печатная форма ведомости маршрутов
|
|
Материальные нормативы
Материальные нормативы в электронном виде по основным и вспомогательным материалам ведутся на предприятии в бюро материальных нормативов. В настоящее время они не связаны непосредственно с технологическими процессами, так как база электронных технологических процессов еще не создана. До внедрения системы для автоматизации ведения материальных нормативов применялось программное обеспечение собственной разработки. Основным недостатком при этом являлось то, что база данных материальных нормативов никак не была связана с конструкторской базой данных и маршрутами. Это сильно затрудняло использование данных материального нормирования при планировании, вызывало множество ошибок и разночтений.
При внедрении системы после проведения первичного импорта данных была выполнена большая работа по корректировке данных, осуществлен переход к единым справочникам материалов, структуры предприятия, видов работ, единиц измерения и других, созданным на предыдущих этапах внедрения системы.
Данные о заготовках и материальных нормах содержат большое количество различных параметров, состав которых зависит от других параметров, например от видов заготовок. Поэтому был разработан и впервые опробован на материальных нормах механизм объектов системы. Он позволяет создавать для некоторого объекта необходимые дополнительные параметры разного типа, в том числе и параметры — ссылки на другие объекты системы, а также вычисляемые или частично вычисляемые параметры. Для вычислимых параметров задаются расчетные формулы.
С использованием механизма объектов для каждого вида заготовок был создан сценарий расчета и представления параметров, заданы формулы расчета, что значительно повысило эффективность работы пользователей. Специалисты предприятия имеют возможность самостоятельно изменять сценарии расчета, добавлять новые виды заготовок и расчетов по ним согласно пожеланиям технологов.
Были реализованы редакторы и бизнес-логика документов, которыми производятся изменения технологической документации — извещения на изменение материальных нормативов. Примеры извещений на изменение материальных нормативов приведены на рис. 7.
Рис. 7. Извещения на изменение материальных нормативов
Требуемые печатные формы, как и в предыдущих случаях, разрабатывались с помощью редактора форм.
Данные о материальных нормах и их изменениях используются в наибольшей степени отделом материально-технического снабжения для расчета потребности в материалах под планы выпуска продукции.
В дальнейшем предполагается ввести данные о нормах расхода вспомогательных материалов в составе электронных технологических процессов.
***
Текущими задачами предприятия по развитию системы управления инженерными данными являются стыковка с конструкторскими системами автоматизированного проектирования и с используемыми на предприятии САПР технологических процессов и решение задач по управлению разработкой и изготовлением оснастки, а также разработкой, изготовлением и ремонтом нестандартного оборудования. Это обеспечит интегрированную среду разработки изделий и их технологической подготовки производства с решением на этой платформе задач планирования, учета и контроля ресурсов.
|
|
