Формирование и ведение бюллетеней серийного изделия в PDM-системе

Такой методологией в  настоящее время и является CALS-технология. Согласно которой основой обработки информации на всём жизненном цикле изделия является ИИС, которая представлена двумя БД: ОБДИ и ОБДПР.

  Согласно CALS-технологии безбумажная технология обработки информации является наиболее оптимальным методом в PDM-системах.

Состав БД

В составе ОБДИ можно (условно) выделить три раздела:

• нормативно-справочный;
• долговременный;
• актуальный.

 

В нормативно-справочном разделе должны храниться информационные объекты (ИО), содержащие данные:

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

 

Содержание нормативно-справочного  раздела ОБДИ обновляется по мере поступления новых и отмены действующих  нормативных документов.

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

• о ранее выполненных готовых проектах (архив);
• типовых узлах и агрегатах собственного производства;
• типовых деталях собственного производства;
• типовых конструктивно-технологических элементах (КТЭ) деталей;
• типовых и групповых технологических процессах;
• типовой технологической оснастке и инструменте;
• готовых и типовых расчетных методиках и математических моделях изделий собственной разработки;
• прочих готовых и типовых решениях.

Долговременный раздел ОБДИ дополняется и обновляется  по мере создания новых технических  решений, признанных типовыми и пригодными для дальнейшего использования.

В актуальном разделе (по-видимому, самом большом по объему и самом сложном по структуре) должны храниться ИО, содержащие данные об изделиях, находящихся на различных стадиях ЖЦ:

 

• конструкции и версиях "текущих" изделий;
• технологии изготовления изделий;
• конкретных экземплярах и партиях изделий в производстве;
• конкретных экземплярах и партиях изделий, находящихся на постпроизводственных стадиях ЖЦ.

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

На предприятии в  данный момент реализованы только Нормативно-справочный и Актуальный разделы.

Нормативно справочный раздел

• КТС УСД
• КЦПИ
• КЦМ
• Перечень СТК
• Перечень цехов
• КТС композиционных материалов
• КТС схем цветовой отделки интерьера изд.204
• ТСН 

 

Актуальный раздел

Для ведения КТС  в состав БДСИ включены в настоящее время следующие первичные документы:

• Конструкторско-технологические спецификации (КТС)
• Доработочные КТС изд.204
• Перечни перечней и перечни чертежей и спецификаций изд.204
• КТС сборочных нормалей (КТСН)
• Листки приостановки изготовления деталей (ПИД)
• Служебные записки УГК
• Бюллетени
• Разовые заказы (РЗ)
• Шифры россыпи (ШР)
• Перечни типовых доработок УГК

  К перечисленным документам  выпускают извещения об изменении  (к бюллетеням, с/з УГК, перечням  доработок – с/з на изменение). Из них информацию вводят в  соответствующие файлы БДСИ в  основном в режиме теледоступа. 

 

Перечень недостатков существующей системы

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

- конструкторско-технологические спецификации

- справочники

- классификаторы

- бюллетени

- разовые заказы

- служебные записки

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

Перечень недостатков существующей системы:

-  дважды переписывается  информация конструктором и оператором

-  растягивается цикл  обработки

-  нет оперативности

-  много посредников,  что увеличивает трудозатраты  на обработку КТД.

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

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

 

1.2.4 Анализ аналогичных разработок

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

 

 

Чтобы разобраться в этом вопросе рассмотрим ряд наиболее лучших зарубежных и отечественных систем: Windchill (PTC, США), Teamcenter (EDS, США), Search (Интермех, РБ) и сравним их с разработкой МЗКТ СпрутМ.

 

Функциональность

PDM Windchill (4 тыс. $/рабочее место) по своей функциональности в основном нацелен на организационную координацию деятельности различных служб, участвующих в разработке и производстве изделия: субподрядчиков по разработке, заказчиков, субподрядчиков по производству, поставщиков комплектующих, а также внутренних подразделений, таких как инженерная служба, маркетинг, продажи, обслуживание, производство, служба снабжения. Информационной поддержки проектирования, технологической подготовки производства у него нет. Заносимая информации с точки зрения конструкторов и последующей АСУ недостаточна: минимальная информация по ДСЕ (деталь-сборочная единица) и составу в приделах 2-х десятков полей. Во многом это типичная система электронного документооборота. Из-за этих недостатков он слабо подходит на роль первичного звена CALS. Стоимость модуля сопряжения Windchill с BAAN порядка 250 тыс. $.

 

БелАЗ промучавшись 7 лет с его внедрением, отказался от закупленных Windchill, BAAN, предпочтя ему Search и старую заводскую систему на Сlipper при их разрозненном использовании. Камнем преткновения явилась проблема синхронизации данных в разных системах построенных по разной бизнес-логике, слишком большой объем вносимой и меняемой информации из-за наличия разных систем, проблема с высококвалифицированными кадрами и разочарование в функционале Windchill и BAAN. Выбор Search был обусловлен, в первую очередь, более низкой ценой и потребностью технологов в модуле Техкард для формирования технологических карт и отсутствием на рынке полноценной PDM. Последний без Search работать не может.

 

Search является типичной системой электронного документооборота с большей ориентацией и поддержкой Автокада (в других модулях). В версии 9 добавлена поддержка UG, ProE, ведение заказных спецификаций и замен, значительно изменен его интерфейс. Предусмотрено варьирование составом, как на уровне головной сборки, так и внутреннем. Данный пакет лучше вышеперечисленных зарубежных настроен на отечественную систему бумажной конструкторско-технологической документации и документооборот. Обеспечивает формирования и распечатку бумажных документов спецификаций на основе информации баз данных, ведение электронного архива чертежей, согласование. Однако заносимая информация Search все же минимальна: только то, что содержится в штампе чертежа, спецификации и извещении и связанная с заменами и вариациями сборок. Организация электронного архива не в полной мере отвечает современным потребностям производства: файлы сбрасываются в папки, они не кодируются в БД, потом сложно с ними разбираться (различать). ERP-функций у него практически нет. Например, отсутствует функция применяемости. И все это из-за ссылочного механизма ведения состава, не позволяющего вести сортировки. Построить полноценную систему CALS при использовании Search в качестве первичного звена сложно, возникает много проблем по интеграции. Сфера применения Search - проектные организации в основном конструкторско-технологического профиля, которым нет необходимости в CALS. Следует отметить, что Search от версии к версии заметно прогрессирует и по своим возможностям во многом уже превзошел TeamCenter. Подводит его наличие ошибок в программном обеспечении.

 

TeamCenter (TCE) позиционируется как PDM система, призванная обеспечить информацией последующие модули EDS, охватывающие подготовку производства и АСУ. Но в СНГ эти модули практически не используются и дать им оценку не представляется возможным. Его PDM также слабо годится на роль первичного звена.

 

 

Преимущества и недостатки

Каждый пакет имеет свои преимущества и недостатки. Функциональность TeamCenter и Windchill в стандартном варианте явно недостаточна. Для применения под отечественную систему документации необходима доработка. Процесс настройки связей для описания объектов в TCE довольно сложен и по опыту ряда организаций (МАЗ, ОКБ Сухого) требуется порядка 3-5 лет. А на занесение полной информации на заводах может уйти до 8-10 лет. Необходимо написание своих программ на Java. Многие организации не в состоянии эти пакеты самостоятельно даже развернуть, не говоря об их модификации. TeamCenter (доработанный отечественными фирмами) несколько лучше чем Windchill адаптирован под производственную сферу в привычном АСУшном понимании. У Windchill уклон сделан на взаимодействие участников и согласование. Windchill слабее с точки зрения обеспечения привычной информацией конструкторов, технологов и АСУ. Работы по созданию надстройки к Windchill из-за слабого его применения в СНГ не ведутся и непонятны причины, по которому его собираются сделать основным в объединенной авиастроительной корпорации России. Единственным объяснением может быть необходимость в обмене данными при кооперации с западными разработчиками.

 

У доработанного TeamCenter содержится несколько больше информации по штампу чертежа и спецификации, к которой привыкли конструктора. PTC (Windchill), похоже, исходит из того, что данная информация должна содержатся в файле самой модели в виде атрибутов. В его БД многие параметры отсутствуют. С точки зрения обеспечения информацией других последующих систем (ERP) он слабее, чем Search, TCE.

 

Механизм ведения заказных спецификаций реализован в TeamCenter за счет дополнительной программной настройки, сделанной в СНГ. В стандартном варианте его нет. У Windchill ведение заказных спецификаций, ERP функций не реализовано. Хотя в принципе возможна его некоторая доработка. Но она требует высококвалифицированных кадров по Java, больших затрат и экономически нецелесообразна из-за присущих ему недостатков.

 

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

 

В отличие от Windchill к TCE можно подключить дополнительно приобретаемые модули: TeamCenter Manufacturing, TeamCenter Project и другие, где заявлена возможность создания техпроцессов, привязки детали к указанному техпроцессу, возможность указания рабочих областей, реализации расцеховки, нормирования материалов, формирования графиков технологического оснащения (формирование, контроль графиков). Но опять, это ПО требует доработки под отечественную систему документации. Информационная поддержка процесса проектирования, особенно конструкторской части у него все же недостаточна. Что касается документов, то они формируются в формате XML. На экране смотрятся нормально, но малопригодны при распечатке. Получить технологические карты невозможно. Требуется модификация БД и разработка дополнительных программ на Java для вывода на печать. А это не каждой организации под силу. Прикрепляемые к карточке документа ДСЕ файлы, как у Windchill и Search неупорядочены, неотсортированы, плохо читаемые и воспринимаемые в дереве. При интеграции с другими системами АСУ у TeamCenter, как и у других пакетов, возникает много проблем. Если в организации не ведется электронный архив (а это наблюдается на многих предприятиях), то перечисленные пакеты вообще не нужны: это лишнее звено.

Заявления фирм-дилеров о возможности серьезной доработки пакетов под ваши задачи во многом пустые обещания. Это связано с самими пакетами (системами их защиты) и их возможностями. В лучшем случае вам сделают интерфейс стыковки, требующий после него ручного редактирования. Подтверждением этому является опыт МАЗа, где за 8 лет смогли добавить в TeamCenter всего лишь одно символьное поле для маршрутов, передаваемое из Omega Soft и реализовать несколько внешних функций по контролю передачи данных в другую систему. Или мучаться с конвертацией данных, прибегая к использованию 2-3х смен (Уралмаш, Search), требующих больших затрат времени при использовании примененного интерфейса.