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

Автор работы: Пользователь скрыл имя, 21 Мая 2013 в 14:29, дипломная работа

Описание работы

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

Содержание работы

СПИСОК ИСПОЛЬЗОВАННЫХ СОКРАЩЕНИЙ И ОБОЗНАЧЕНИЙ…….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

Файлы: 1 файл

Poyasnitelnaya_zapiska_Valeev.doc

— 1.93 Мб (Скачать файл)

 

Если бы удалось объединить положительные стороны этих пакетов, включая СпрутМ, получилась бы идеальная система. А пока с точки зрения конструкторско-технологических служб и АСУ в рассматриваемых первых трех пакетах много недостает, их структура должна быть иная и поддерживаться больше за счет реляционных баз. Нет цепочки ДСЕ – изменение – извещение – их содержание (графика). Согласно ЕСКД извещение может выпускаться только на конкретное изделие или на группу. На конкретную ДСЕ оно не выпускается. Фактически, не к чему в рассматриваемых 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-системе