Разработка прикладного программного обеспечения

ДипломнаяПомощь в написанииУзнать стоимостьмоей работы

Разработка прикладного программного обеспечения (реферат, курсовая, диплом, контрольная)

Введение

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

Поэтому в данном дипломном проекте рассматриваются вопросы разработки уникальной PDM-системы предназначенной для внедрения в производство предприятия «Авиастар СП». Рассматриваются вопросы обработки основных конструкторских документов служебных записок, разовых заказов и шифров россыпи в электронном виде (безбумажной технологии)

Список использованных сокращений и обозначений

CALS-технологии (Continuous Acquisition and Life cycle Support) — непрерывная информационная поддержка поставок и жизненного цикла

PDM-система (Product Data Management) — система управления данными об изделии РЗ — разовый заказ СЗ — служебная записка ШР — шифр россыпи АБД — отдел администратора базы данных БПБД — Бюро проектирования баз данных ОБДИ — общая база данных об изделии ОБДП — общую базу данных о предприятии БАО КТД — бюро автоматической обработки конструкторско — технической документации БДСИ — база данных состава изделия ЭВМ — электронная вычислительная машина БД — база данных СТП — стандарт по выпуску ИТ — информационные технологии КТС — конструкторско-техничекая спецификация СБЕ — сборочных единиц ИИС — интегрированная информационная система ЖЦ — жизненных цикл БЛ — бюллетень СУБД — система управления базами данных АРМ — автоматизированное рабочее место

1. Назначение и цели создания системы

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

Данный проект разрабатывается на исходных данных отдела АБД (администратора базы данных состава изделия). Тема диплома реализуется на предприятии ЗАО «Авиастар СП» в 395 отделе.

1.2 Цели создания системы Цели ставящиеся перед отделом администратора базы данных при разработке новой технологии:

— сокращение финансовых затрат — уменьшение трудоемкости при обработке документации

— сокращение времени обработки информации

— оперативность и качество принимаемых управленческих решений для конструкторов

2. Характеристика объекта автоматизации

2.1 Общее описание Объектом автоматизации является PDM-система завода «Авиастар СП». В соответствии с методологией CALS PDM-система является одной из основных частей ИИС предприятия. Отдел АБД в соответствии с его функциями и назначением занимается созданием и ведением PDM-системы.

В соответствии с современной концепцией при разработке наукоемких изделий в настоящее время идет внедрение CALS-технологий и одним из ее компонентов является PDM-система. Эта система все более находит применение на предприятии «Авиастар СП»

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

2.2 Структура и принципы функционирования Отдел администратора базы данных в течении десятилетий занимается разработкой данной тематики и в связи с этим приводится функциональная структура подразделения, которая занимается созданием этой PDM-системы.

Организационная структура отдела.

В состав ОАБД входят следующие структурные звенья

§ Бюро проектирования баз данных (БПБД)

§ Бюро автоматизированной подготовки конструкторско-технологической документации (БАО КТД).

§ Бюро ведения баз данных (БВБД) Организационная структура и штаты ОАБД утверждаются генеральным директором ЗАО «Авиастар СП» в установленном порядке.

Функции отдела.

Основные задачи:

§ Обеспечение создания, ведения и функционирования баз данных:

— «Состав изделия» /БДСИ/

— «Разовых заказов» /БДРЗ/

— «Бюллетеней» /БДБЛ/

— «Шифров россыпей» /БДШР/

§ Обеспечения входного контроля, перфорации и ввода конструкторскоготехнологической документации в эксплуатируемые базы данных.

§ Поддержание полноты, достоверности и актуальности информации в эксплуатируемых базах данных.

Общие функции для всех бюро:

§ Изучают процессы обработки и ведения КТД в производстве и возможные их формализации и автоматизации обработки на ЭВМ.

§ Разрабатывают предложения, в планы проектирования, создания баз данных, планы ОТМ. Технического перевооружения.

§ Определяют необходимые данные и разрабатывают техническое задания на проектирования баз данных, отдела задач АСУ.

§ Проводятся работы по совершенствованию документа оборота УГК, УГТ, разрабатывают предложения для УГК, УКТ по улучшению технологии обработки технической информации, используемой для создания БДСИ.

§ Разрабатываю необходимые организационные документы.

§ Изучают и внедряют передовой опыт по ведению и обработки КТД на ЭВМ.

§ Оказывают методическую помощь подразделениям по вопросам подготовки и внедрения задач в эксплуатацию с помощью БДСИ.

§ Разрабатывают готовые, месячные планы-отчеты.

Бюро проектирования баз данных.

§ Проектирует концептуальную логическую и физическую модели баз данных.

§ Разрабатывает программную и эксплуатационную документации по созданию и ведению баз данных, телеобработки.

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

§ Совершенствует тех. процессы по задачам на этапе сдачи в промышленную эксплуатацию.

§ Разрабатывает программное обеспечение по вводу и созданию входных массивов с первичных документов.

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

§ Определяет перечень файлов баз данных и связи между ними.

§ Разрабатывает средства защиты и безопасности баз данных от несанкционированного доступа.

§ Разрабатывает технологические средства, методы корректировки и поиска информации в БД.

§ Разрабатывает методические и инструктивные руководства по корректировке и поиску информации в БД.

§ Осваивает и внедряет интерактивные языки запросов БД.

§ Разрабатывает программы связи теледоступа к конкретным БД.

§ Разрабатывает методы логического контроля ошибок, допущенных при оформлении КТД и перфорации.

Бюро автоматизированной обработки конструкторско-технической документации:

§ Производит подготовку документов к пакетному вводу, регистрацию, входной контроль.

§ Запись информации на магнитные ленты и другие машинные носители.

§ Предает магнитные ленты на ИВЦ для ввода в ЭВМ с последующим контролем и коррекцией по результатам обработки на ЭВМ.

§ Прорабатывает справки ежедневных порций ввода, справки накопительного массива.

§ Передает информацию на магнитных лентах и других носителях в отдел 023 для ввода в базы данных после действий проведенных согласно п. 4.3.3.

Бюро ведения в базы данных.

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

§ Отрабатывает со службами рассогласования, выявленные в процессе проработки КТД по п. 4.4.1. Оформляет с записки на возврат КТД разработчику для внесения изменений по замечаниям работника бюро.

§ Корректирует информацию в базе данных в режиме теледоступа согласно КТД.

§ Разрабатывает инструкции, положения, графики выполнения работ.

§ Прорабатывает МГ по результатам проведения логического контроля, корректировки БД после обработки МГ со службами ЗАО.

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

§ Работает со службой главного конструктора по устранению оборванных связей, выявленных процессе ежемесячного логического контроля.

§ Разрабатываем предложения по созданию и ведению БД, участвует в оформлении эксплуатационной документации.

§ Оказывает методическую помощь в решении и сопровождении задач, разрабатываемых БПБД отдела.

§ Выдает справки по телефону по запросам производства ЗАО Авиастар СП. Выявляет рассогласования в базе данных с исходных документам. Определяет исполнителя для принятия решения по устранению ошибок перфорации или уточнения КТД разработчиком документа.

Схема организационной структуры отдела администратора базы данных состав изделия.

Рис. 1. Организационная структура отдела АБД

2.3 Существующая информационная система и её недостатки Одними из основных компонентов документооборота обрабатывающихся в PDM-системе являются служебные записки, разовые заказы, шифры россыпи.

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

Центральной и главной в PDM-системе является конструкторско-технологическая спецификация (КТС) раскрывающая «Состав изделия». На ее основе формируется таблица серийного изделия КТС при бумажной технологии ведения.

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

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

Схематически разделы СЗ можно представить так: Таблица № 1


Схема состава бумажной СЗ
1.Тектовая часть СЗ
2.Перечень СЗ (детали + материалы + головные СБЕ (сборочных единиц) + стандартные изделия)
3.КТС дополнительных СБЕ (сборочных единиц)
4.КТС раскрытых головных СБЕ (сборочных единиц)

Все эти разделы СЗ формировались вручную на бумажных носителях.

По заявкам сторонних организаций выпускались РЗ (разовые заказы).

Разовые заказы (РЗ) — определяют номенклатуру подлежащую изготовлению по заявкам заказчиков.

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

Состав СЗ, РЗ, ШР аналогичен. Отличие между ними заключается в нескольких процентах друг от друга по реквизитному составу и алгоритму формирования.

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

С развитием БД и увеличением частоты и объема документов СЗ, РЗ, ШР такая технология их обработки имеет большую трудоемкость и большой цикл внедрения. Особенно трудоемким был раздел СЗ по раскрытию состава по всем уровням вхождения головных СБЕ (сборочная единица) из перечня СЗ, то есть разузлования. Поэтому была разработана новая схема СЗ, РЗ, ШР.

Таблица № 2


Новая схема формирования РЗ, СЗ, ШР
1.Тектовая часть СЗ, РЗ, ШР
2.Перечень СЗ (с указанием обозначения детали, сборочной единицы, серии, количества заказа и цеха потребителя). Остальные реквизиты пустые и подбираются из БД.
3.Лист изменения к серийным КТС, которые вводятся ЭВМ при раскрытии состава головных СБЕ.
4.Дополнительные КТС.
5. Раскрытый состав СЗ, РЗ, ШР формируется на ЭВМ. (90% всей трудоемкости занимает этот пункт.)

Особенно трудоемким является последний раздел СЗ, если в него включается тысячи ли десятки тысяч записей. Объем СЗ, РЗ, ШР со временем существенно возрос и составляет 50−60% от серийного объема КТС изделия 204.

Разработанная схема СЗ, РЗ, ШР позволила автоматизировать процесс разработки и формирования данных документов в PDM-системе, на бумажных носителях первых четырех разделов и пятый раздел выполнить на ЭВМ. Состав существующей базы данных.

Существующая PDM-система согласно CALS-технологии представляется общей базой данных об изделии. На предприятии общая база данных об изделии должна содержать разделы: нормативно-справочный, актуальный и долговременный. Но на предприятии на данный момент существует лишь два раздела нормативно-справочный и актуальный.

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

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

нормативно-справочный;

долговременный;

актуальный.

В нормативно-справочном разделе должны храниться ИО, содержащие данные:

о конструкционных материалах;

о нормализованных деталях (нормалях);

о стандартных (покупных) комплектующих изделиях;

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

Рис. 2 Общая база данных об изделии

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

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

ранее выполненных готовых проектах (архив);

типовых узлах и агрегатах собственного производства;

типовых деталях собственного производства;

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

типовых и групповых технологических процессах;

типовой технологической оснастке и инструменте;

готовых и типовых расчетных методиках и математических моделях изделий собственной разработки;

прочих готовых и типовых решениях.

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

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

конструкции и версиях «текущих» изделий;

технологии изготовления изделий;

конкретных экземплярах и партиях изделий в производстве;

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

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

В разделе, посвященном экономике и финансам, должны храниться ИО, содержащие сведения:

о конъюнктуре рынка изделий предприятия, включая цены и их динамику;

о состоянии финансовых ресурсов предприятия;

о ситуации на фондовом и финансовом рынках (курсы акций предприятия, биржевые индексы, процентные ставки, валютные курсы и т. д.);

о реальном и прогнозируемом портфеле заказов;

прочие сведения финансово-экономического и бухгалтерского характера.

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

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

о производственной структуре предприятия;

о технологическом, вспомогательном и контрольно-измерительном оборудовании;

о транспортно-складской системе предприятия;

об энерговооруженности предприятия;

о кадрах;

прочие данные о предприятии.

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

о структуре действующей на предприятии системы качества;

о действующих на предприятии стандартах по качеству;

о международных и российских стандартах по качеству;

о должностных инструкциях в области качества;

· прочая информация по системе качества.

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

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

· КТС УСД

· КЦПИ

· КЦМ

· Перечень СТК

· Перечень цехов

· КТС композиционных материалов

· КТС схем цветовой отделки интерьера изд.204

· ТСН Бюллетень — документ, определяющий работы по поддержанию и улучшению ТТД и эксплуатационных характеристик, повышение надежности и устранению производственных и конструктивных недостатков авиационной техники Служебная записка типа «БЛ» — документ, которым запускается бюллетень на предприятии.

Служебная записка типа «СД» — документ, определяющий порядок доработки ВС;

Технологический паспорт — определяющий перечень работ с подтверждением их выполнения;

Технический акт — документ о выполнении работ;

Договор — документ, определяющий объемы доработок по бюллетеням по конкретному заказчику.

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

· Конструкторско-технологические спецификации (КТС)

· Доработанные КТС изд.204

· Перечни перечней и перечни чертежей и спецификаций изд.204

· КТС сборочных нормалей (КТСН)

· Листки приостановки изготовления деталей (ПИД)

· Служебные записки УГК

· Бюллетени

· Разовые заказы (РЗ)

· Шифры россыпи (ШР)

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

Недостатки существующей системы:

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

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

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

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

— бюллетени

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

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

Недостатки существующей системы:

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

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

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

— существующая система работает в пакетном и диалоговом режиме функции которого выполняются отделом АБД

— неразвитая система телеобработки недостаточно развитая (конечный пользователь может только читать информацию из БД)

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

Такое количество ошибок вынуждает создавать более автоматизированную и модернизируемую информационную систему.

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), требующих больших затрат времени при использовании примененного интерфейса.

Если бы удалось объединить положительные стороны этих пакетов, включая СпрутМ, получилась бы идеальная система. А пока с точки зрения конструкторско-технологических служб и АСУ в рассматриваемых первых трех пакетах много недостает, их структура должна быть иная и поддерживаться больше за счет реляционных баз.

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

Каждый рассматриваемый пакет ориентирован на свои модули, за которые надо отдельно платить. Полноты охвата функционала нет ни у одного импортного пакета. У многих пакетов нет функций формирования требующихся нам документов из-за отсутствия информации. Как уже указывалось у Windchill и Search нет своего модуля ERP. Поэтому многие используют ERP, другого разработчика или собственные разработки. Но чтобы все это нормально работало, необходимо, чтобы последующие модули придерживалось той же бизнес-логики и имели аналогичную структуру данных. А этого нет.

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

Обычно на практике никто не работает в 3-D с такими сложными изделиями целиком, в основном по узлам. Если создается компоновка, то, как правило, делается на упрощенных моделях-составляющих — в противном случае не вытянут компьютеры. В этом случае возникают вопросы, а из чего строить дерево сборки: с действительных моделей или упрощенных и как их потом различать в PDM при отсутствии кодирования. Ответов пока нет.

Комплексная оценка пакетов Для указанных PDM характерно занесение информации по обозначению в одно поле и использование ссылочного механизма при ведении базы данных состава (запись номера ДСЕ вместо обозначения). Все это приводит к невозможности выполнения сортировок по частям обозначения как по ДСЕ так составу. Это принципиальные недостатки перечисленных систем, которые накладывают много ограничений на дальнейшее использование их информации в других систем. Ведь без сортировок нельзя обойтись, особенно когда номенклатура изделий предприятий составляет сотни тысяч. Теряется информативность, можно легко пропустить при просмотре требующуюся информацию. Все это вынуждает внедрять дополнительные системы, включая собственные. А это ведет к необходимости дублировать ввод информации, объемы которой сейчас резко возрастают. Необходимо подключение технологов на ранней стадии еще до утверждения КД и обеспечения их необходимой информацией. Фактически сейчас имеется большая потребность, чтобы PDM помимо своих стандартных функций выполнял часть функций ERP систем. Именно в этом направлении ведется совершенствование СпрутМ.

Использование PDM Windchill, TeamCenter некоторыми российскими азрокосмическими КБ обусловлено спецификой их деятельности. У них КБ отделены от производства и применяется Unix на 64-х битных рабочих станциях для возможности работы с очень большими сборками. Задача этих КБ выпустить документацию, включая электронную. Вопросы интеграции с другими производственными системами считались не их сферой. Мол это проблемы заводов, которые выпускают их изделие. А производство больше ориентировано на ERP, а не PDM. Хотя сейчас начинают понимать в потребности в PDM и на производстве, чтобы разобраться с комплектацией. Вторая причина, что других пакетов под ОС Unix нет и надо как-то автоматизировать и координировать 3-хмерное проектирование и вести электронный архив. И поэтому приходится мириться с недостатками этих PDM.

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

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

Одновременно необходимо учитывать, что многие зарубежные пакеты также плохо подходят и по блоку экономических и финансовых задач из-за другого законодательства, форм документов. То же можно сказать о технологическом блоке в части форм документов. Поэтому имеются большие сомнения в эффективности использовании зарубежных пакетов АСУ. Потребуется много доработок и подключения своих систем. Исключение составляет моделирование техпроцессов, неплохо решенное в технологических модулях PTC и EDS. Но это автономные модули больше ориентированные на графические пакеты. Они могут работать и без PDM-ERP указанных фирм. Чтобы получить отдачу от CALS надо сочетать и импортные пакеты (их отдельные модули) и свои, например: импортные графические пакеты и развивать свои CALS-системы, перенимая положительные моменты. Гораздо хуже слепое преклонение перед оторванными от реального производства заморскими продуктами, проведение технической политики, заводящей в тупик собственные разработки и обрекающей нас на технический застой.

Важно понять, что если выбираем PDM Windchill, TeamCenter, SAP или им подобную то всю последующую ИИСП надо строить либо на основе их модулей или по их идеологии: применять обозначение в одно поле, использовать ссылочный механизм ведения состава, осуществлять изменение путем формирования новой спецификации и изменение статуса старой. А это повлечет за собой много указанных выше проблем и снизит функциональность и эффективность всей системы. Многих требующихся нам функций у них нет. Все дальнейшее построение интегрированной информационной системы предприятия при таком подходе пойдет не так, как хотелось. Из других систем нельзя будет изменять данные реализуемые PDM. Внедрение таких «PDM» потребует кардинальной перестройки всей системы предприятия, его ломку, создания конверторов, применения дополнительных пакетов, реализующих недостающие функции, полного переоснащения техникой Приобретать такие PDM (СЭД) ради осуществления только красивого механизма электронного согласования и визуализации вряд ли целесообразно. С точки зрения наших предприятий это не является столь первоочередным и особо важным. Редко кто из предприятий, применяющих PDM, использует эту функцию, т.к. согласование это своеобразный торг конструктора и технолога и требует личного контакта. Визуализацию можно решать по-другому. Например, используя COM-Java технологии запускать из пакета сторонние 3-D редакторы и загружать файлы, как это сделано в СпрутМ. Или формировать в нем html страницы и запускать из него интернет-браузер для просмотра упрощенных 3D моделей. Единственное, что надо сделать: осуществить заранее вручную преобразование полной модели в упрощенную через 3-D редактор. У Windchill это делается динамически на сервере без участия человека, но требует мощных серверов. У СпрутМ применяется более простой механизм текстового электронного согласования и электронной подписи с идентификацией файлов, введен механизм замечаний с прикрепляемыми файлами графики, есть ведение заказных спецификаций и многих ERP задач.

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

Кроме того, западные продукты более ориентированы на верхний уровень управления, а не на средний и нижний, что сейчас больше необходимо нашим предприятиям. Стоимость одного рабочего места такого PDM не маленькая 4−6 тыс. $ /рабочее место (Windchill), 39 тыс. € для UG c TeamCenter, Search (3 тыс. $), а их требуется на предприятии несколько сотен, не учитывая других систем. Слишком дорогая цена за функцию согласование. Реально у большинства предприятий сейчас таких средств нет, тем более на кардинальное обновление всей системы предприятия. ИИСП — это комплексная система, где все должно работать во взаимодействии. И если какой-то модуль не вписывается в общее информационную среду, то лучше им пожертвовать.

На предприятии «Авиастар СП» на данный момент идет разработка своей уникальной PDM-системы, т. к имеющиеся стандартные системы не подходят этому предприятию и не могут быть использованы.

На авиастаре приходится разрабатывать собственную PDM — систему так как если использовать имеющиеся сейчас PDM предприятие скатится к организационно-распорядительным функциям и не построится интегрированная информационная система — полноценная CALS/PLM система. Вложив большие средства мы не получим в итоге отдачи. И такие отрицательные результаты в РБ и СНГ уже есть, а главное потеряем веру в собственные возможности.

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

2.5 Актуальность проводимой разработки Появление новых средств вычислительной техники позволило разработать безбумажную технологию обработки информации (использовать современные СУБД, объектно-ориентированные пакеты, операционные системы). Поэтому проводится перепроектирование старой и разработка новой системы.

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

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

3. Общие требования к системе Система должна совмещать старую и новую технологию и функции обработки КТД. Изделие ранее запущенное в производство должно учитывать, что будет работать старый бумажный канал, ввод с бумажных носителей, загрузка в перечень РЗ, СЗ, ШР и раскрытие через отдел АБД.

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

Требования к PDM системе Обобщая опыт разработки и внедрения различных PDM систем в различных отраслях промышленности можно выделить ряд критериев, которым должна соответствовать современная PDM система:

Открытая информационная модель. Структура БД при необходимости может быть дополнена различными информационными объектами в соответствии с требованиями конкретного предприятия.

Соответствие международным CALS-стандартам, которое необходимо не только для построения ядра интегрированной информационной среды (ИИС) предприятия, но и для успешного взаимодействия с иностранными партнерами. Изначальная ориентация системы на решение задач в масштабе предприятия, а не рабочей группы.

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

Взаимодействие с другими автоматизированными системами.

Один из первых вопросов, возникающих при внедрении систем класса PDM:

«как система впишется в существующие автоматизированные системы предприятия?». Внедрение PDM изначально предполагает импорт данных из уже существующих на предприятии БД и интеграцию с имеющимися автоматизированными системами. При этом большинство потоков информации должно проходить через PDM-систему.

PDM-система должна предоставлять два способа обмена данными:

— Через обменный файл STEP (преимущественно для обмена с CAD/CAM-системами, с которыми нет прямой интеграции).

— Прямая интеграция посредством полнофункционального интерфейса доступа к данным (API), который является реализацией стандартного интерфейса доступа к данным.

разовый заказ служебный записка

4. Требования к функциям, выполняемым системой

— ввод РЗ, СЗ, ШР (теста и эскиза)

— ввод перечня РЗ, СЗ, ШР

— формирование раскрытого состава РЗ, СЗ, ШР

— контроль проработки

— загрузка в базу утвержденных Требования к функциям PDM-системы.

управление инженерными данными (engineering data management — EDM)

управление документами управление информацией об изделии (product information management — PIM)

управление техническими данными (technical data management — TDM)

управление технической информацией (technical information management — TIM)

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

управление хранением данных и документами управление потоками работ и процессами управление структурой продукта автоматизация генерации выборок и отчетов механизм авторизации

5. Требования к видам обеспечения

5.1 Требования к математическому обеспечению

— алгоритм ввода СЗ, РЗ, ШР

— алгоритм раскрытия

— алгоритм корректировки раскрытых РЗ, СЗ, ШР

— алгоритм ввода бумажных СЗ, РЗ, ШР

— алгоритм контроля РЗ, СЗ, ШР

5.2 Требования к информационному обеспечению

— Необходимость использовать СУБД.

— В настоящее время на предприятии существует СУБД Oracle 8, на основе этой базы данных будет формироваться БД РЗ, СЗ, ШР.

— ввод с бумажных носителей и безбумажных технологий

— Многопользовательский режим доступа к данным

— Необходимость запрета несанкционированного доступа к данным, авторизации доступа

— содержание паролей обеспечивает защиту

— Необходимость архивации данных

5.3 Требования к техническому и программному обеспечению Необходимым условием эффективной работы является надежность и быстродействие программного обеспечения. Поэтому построение системы по трехуровневой схеме «клиент — сервер приложений — сервер БД», когда доступ к данным осуществляется через промежуточное звено — сервер приложений, дает значительные преимущества по сравнению с двухуровневой. Сервер приложений значительно уменьшает нагрузку на сервер БД и обеспечивает эффективную работу до 5 клиентов на одном сервере приложений и позволяет значительно увеличить количество клиентов, работающих с одним массивом данных.

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

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

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

Программное обеспечение сервера СУБД выполнено в виде хранимых процедур СУБД Oracle 8.i. Доступ к БД осуществляется только через хранимые процедуры. Вызов хранимых процедур с промежуточного сервера осуществляется с использованием программного интерфейса OCI (Oracle Call Interface). Программное обеспечение клиентского модуля обеспечивает диалоговое взаимодействие с БД данных через сервер приложений, занесение и редактирование данных, настройку статических данных, настройку программ, входящих в систему. Клиент так же осуществляет доступ к данным через программный интерфейс (API).

Сервер БД Минимальные:

Windows 2000, Oracle 8.1.7 Server.

Pentium 2000 800 МГц, RAM 512 МБ, NetCard 100 Мбит.

Также необходимо предусмотреть устройства резервного копирования и бесперебойного питания.

Промежуточный сервер (сервер приложений) Минимальные:

Windows XP or Highter/Linux/FreeBSD Oracle 8.1.7 Client.

Pentium x4 2000 МГц, RAM 2Gb, 500 Gb на HD, NetCard 100 Мбит.