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

ЗАДАНИЕ НА ДИПЛОМНЫЙ ПРОЕКТ

 

студент _________Валеев Н.Р._________________код ________группа АИСТд-51

фамилия, инициалы

1.Тема:

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

утверждена приказом по________________________________ № ______________

аббревиатура учебного заведения

от “___”___________ 2010 г.

 

2. Срок предоставления проекта к защите “ 10” июня 2010г.

3. Исходные данные для проектирования: КТС бюллетеня, Описание процесса формирования бюллетеня, Стандарт по выпуску бюллетеня, нормативные требования по стандартизации, охране труда и защите окружающей среды.

4. Содержание пояснительной записки

4.1. Анализ системы формирования и ведения бюллетеня.

4.2. Формирование требований к разрабатываемой ИС

4.3. Разработка модели данных, информационных процессов и архитектуры информационной системы отдела.

4.4. Разработка технического обеспечения системы

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

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

4.7. Оценка экономической эффективности модификации информационной системы отдела

 

 

5. Перечень графического материала: ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

 

6. Консультанты по разделам:

Раздел	Консультант	Подпись,	дата
		Задание выдал	Задание принял
Аналитический	Недоцуков Н.А.
Программно-технологический	Недоцуков Н.А.
Организационно-экономический	Руднев С.Н.
БЖД	Попов Н.А.

Руководительпроекта:___________________________ Недоцуков Н. А. __________

подпись, дата инициалы, фамилия

Задание принял к исполнению_____________________ Валеев Н.Р. _____________

подпись, дата инициалы, фамилия

 

 

Аннотация

Дипломный проект Валеева Наиля Рифкатовича по теме «Формирование и ведение бюллетеней в PDM-системе. Руководитель Недоцуков Николай Акимович. Защищен на кафедре «Самолетостроение» в 2010г.

Пояснительная записка 98 с., 4 разд., 1 прил., 4 табл., Графическая часть: 5 лист.

Ключевые слова

ЗАО «Авиастар-СП», отдел 084, PDM, CALS, Бюллетень.

 

 

Данный проект разрабатывается на исходных данных отдела АБД (администратора базы данных состава изделия). Тема диплома реализуется на предприятии ЗАО «Авиастар СП» в 395 отделе. Информационная Система ведения документооборота в PDM системе предназначена для сотрудников «Авиастар-СП» для автоматизации ведения документооборота внутри предприятия. ИС реализована на языке C++, Builder. ИС состоит из четырех основных модулей: «ввод бюллетеня из текстового файла», «просмотр и корректировка перечня бюллетеня», «раскрытие состава бюллетеня», «корректировка применяемости раскрытых бюллетеней». Данная реализация представляет АРМ по обработке бюллетеня с рабочих мест конструктора и технолога в электронном виде. Разработка рекомендована к внедрению в производство ЗАО «Авиастар-СП».

 

Содержание

СПИСОК ИСПОЛЬЗОВАННЫХ СОКРАЩЕНИЙ И ОБОЗНАЧЕНИЙ …….7

ВВЕДЕНИЕ …………………………………………………………………..………..8

1.Аналитический раздел …………………………………………………………9

Техническое задание на создание системы ……………………………………….10

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

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

1.2.1 Общее описание……………………………...………………………….……10

1.2.2 Структура и принципы функционирования………………………...………10

1.2.3 Существующая информационная система и её недостатки……………….15

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

1.2.5 Актуальность проводимой разработки……………………………………...32

 

2.Конструкторский раздел …………………………………..…………………33

1.3 Общие требования к системе………………………………………………….34

1.3.1 Требования к структуре и функционированию системы………………….34

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

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

1.5.1 Требования к математическому обеспечению……………………………..35

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

1.5.3 Требования к программному и техническому обеспечению……….……..36

2 Модель исходной информационной системы ……………………………….38

3 Информационное обеспечение системы ………….…………………………..41

3.1 Выбор средств управления данными……………………………………….41

3.2 Проектирование базы данных……………………………………………....42

3.2.1 Логическая модель данных…………………………………………….….42

3.2.2 Физическая модель данных……………………………………………….47

3.4 Организация сбора, передачи, обработки и выдачи информации……….53

3.Программно – технологический раздел …..……..…....…………………55

4 Математическое обеспечение системы …………………………..………....56

4.1 Алгоритм конвертирования с БЭВМ……………………………………….56

4.2 Алгоритм ввода с текстового файла ПБ и КТСБ……………………….….56

4.3 Алгоритм формирования перечня бюллетеня в режиме теледоступа…...56

4.4 Алгоритм раскрытия состава СБЕ ПБ и формирования КТСБ…………...56

4.5 Алгоритм печати бюллетеня………………………………………………..57

5 Программное обеспечение системы …………………………………………57

5.2.1 Операционная система…………………………………………………….57

5.2.2 Инструментальное средство разработки и язык программирования…..58

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

5.3.2 Программный модуль Ввода БЛ………………………………………….61

5.3.2 Программный модуль просмотра и корректирования ПБ и КТСБ...….63

6 Тестирование системы ……………………………………………………….66

4 ЭКОЛОГИЯ И БЕЗОПАСНОСТЬ ЖИЗНЕДЕЯТЕЛЬНОСТИ …………….70

4.1 Безопасность жизнедеятельности…………………………………………….70

4.2 Требования перед началом работ……………………………………………..73

4.3 Требования безопасности во время работы………………………………….75

4.4 Требования безопасности в аварийных ситуациях………………………….77

4.5 Требования безопасности по окончании работы…………………………….78

4.6 Ответственность за нарушение требований инструкции……………………78

4.7 Мероприятия по обеспечению безопасности и условий труда……………..79

4.8 Расчет освещенности…………………………………………………………..81

4.9 Расчет вентиляции……………………………………………………………..82

4.10 Расчет мощности кондиционера…………………………………………….84

4.11 Вывод………………………………………………………………………….85

5 ОРГАНИЗАЦИОННО – ЭКОНОМИЧЕСКИЙ РАЗДЕЛ ……………………87

5.1 Выбор метода оценки экономической эффективности……………………..88

5.2 Расчет себестоимости программы……………………………………………92

5.3 Расчет трудовых и стоимостных затрат………………………………….…..93

5.4 Расчет трудовых показателей экономической эффективности………..……94

5.5 Расчет стоимостных показателей экономической эффективности……..….95

ЗАКЛЮЧЕНИЕ ………………………………………………………….…………..98

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ …………………….………99

ПРИЛОЖЕНИЯ …………………….………………………………………………100

 

 

Введение

Объектом автоматизации данной дипломной работы является одна из функций PDM-системы. Функция автоматизации выпуска и обработки информации по бюллетеням. В процессе выпуска изделия и отправки эксплуатантам, в результате эксплуатации выявляются некоторые конструктивные недоработки. Чтобы устранить их необходимо внести изменения в конструкцию. Отдел бюллетеней выпускает конструкторско-технологические изменения к изделию. В результате чего формируется бюллетень, который отправляется эксплуантантам, Они в соответствии с бюллетенем производят изменения.

 

Проблему повышения конкурентоспособности наукоемкого

промышленного изделия – можно решить за счет удовлетворения

требований заказчика и сокращения временных и материальных издержек

предприятия. Все это может быть достигнуто за счет повышения

эффективности процессов жизненного цикла изделия (ЖЦИ).

В связи с увеличением сложности изделий и использованием для их

создания современных компьютерных систем, увеличивается объем данных

об изделии, и старые методы работы с ними уже не в состоянии обеспечить

их точность, целостность и актуальность. А также, в связи с большим

количеством участников проекта возникают серьезные проблемы, связанные

с обменом данными между участниками, выражающиеся в наличии

коммуникационных барьеров.

 

 

1. АНАЛИТИЧЕСКИЙ РАЗДЕЛ
					ДП 23020165.07.001.-10.ПЗ
Изм	Лист	№ Докум.	Подп.	Дата
Разраб.	Валеев			ПОЯСНИТЕЛЬНАЯ ЗАПИСКА	Литер.	Лист	Листов
Пров.	Недоцуков				У
Рецензия				УлГТУ ИАТУ Гр. АИСТд-51
Н.контр.
Утв.	Щеклеин

Основная часть

1 Техническое задание на создание системы

Назначение

Данные проект разрабатывается на исходных данных отдела АБД (администратора базы данных состава изделия). Тема диплома реализуется на предприятии ЗАО Авиастар СП и направлена на создание автоматизированного рабочего места (АРМ) по обработке бюллетеней в PDM-системе.

Цели

При разработке системы направленной на автоматизацию создания и ведения бюллетеней ставятся следующие цели:

§ Сократить финансовые затраты на разработку бюллетеня

§ Сократить длительность процесса обработки бюллетеня в отд 384.

§ Снизить трудоемкость формирования бюллетеня

§ Повысить производительность труда

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

Общее описание

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

 

PDM - система разрабатывается отделом администрации базы данных предприятия ЗАО Авиастар СП.

 

Главные идеи CALS

Пути решения перечисленных проблем предлагает концепция CALS.

Согласно этой концепции, промышленным предприятиям необходимо

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

на протяжении всего ЖЦ, а также направить свои усилия на преодоление

коммуникационных барьеров между участниками ЖЦ изделия. Это

позволит повысить эффективность процессов ЖЦ и эффективность

взаимодействия между участниками ЖЦ. Такое повышение эффективности

приведет к снижению временных и материальных издержек в течение ЖЦ

изделия и качества продукции, в это, в свою очередь, неизбежно принесет

повышение конкурентоспособности промышленного изделия.

Рассматриваемая группа CALS-технологий состоит из известных методов,

реализованных в соответствующих автоматизированных системах.

Технологии интеграции данных об изделии реализуются с помощью

класса автоматизированных систем, называемых системами управления

данными об изделии (Product data management – PDM).

 

 

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

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

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

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

§ Бюро ведения баз данных (БВБД)

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

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

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

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

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

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

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

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

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

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

 

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

 

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

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

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

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

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

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

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

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

§

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

 

 

 

Состав БД

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

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

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

Ø актуальный.

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

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

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

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

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

Ø о стандартных расчетных методах;

Ø о государственных, международных и внутренних стандартах;

Ø о прочих нормативных документах.

 

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

· КТС УСД

· КЦПИ

· КЦМ

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

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

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

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

· ТСН

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

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

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

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

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

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

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

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

· Бюллетени

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

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

· Перечни типовых доработок УГК

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

 

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

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-системы, перенимая положительные моменты. Гораздо