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

Главная

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

Автоматизации формирования и ведения разовых заказов, служебных записок и шифров россыпи на предприятии ЗАО "Авиастар СП". Инструментальное средство разработки и язык программирования. Расчет себестоимости программы, трудовых и стоимостных затрат.


посмотреть текст работы


скачать работу можно здесь


полная информация о работе


весь список подобных работ


Нужна помощь с учёбой? Наши эксперты готовы помочь!
Нажимая на кнопку, вы соглашаетесь с
политикой обработки персональных данных

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Наиболее важным вопросом для предприятий остается правильный выбор PDM-системы. В то же время, современный рынок PDM-систем насчитывает сотни как интегрированных, так и автономных PDM-продуктов, рассчитанных на решение глобальных или локальных задач, а также ориентированных на финансовые возможности предприятия. С одной стороны, выбор велик. С другой стороны, существуют отрасли, для которых до сих пор не разработано удовлетворительных PDM-решений. Поэтому можно сказать, что практически каждое предприятие должно при выборе PDM-системы идти своим путем.
Поэтому в данном дипломном проекте рассматриваются вопросы разработки уникальной PDM-системы предназначенной для внедрения в производство предприятия «Авиастар СП». Рассматриваются вопросы обработки основных конструкторских документов служебных записок, разовых заказов и шифров россыпи в электронном виде (безбумажной технологии)
Список использованных сокращений и обозначений
CALS-технологии (Continuous Acquisition and Life cycle Support) - непрерывная информационная поддержка поставок и жизненного цикла
PDM-система (Product Data Management) - система управления данными об изделии
АБД - отдел администратора базы данных
БПБД - Бюро проектирования баз данных
ОБДИ - общая база данных об изделии
ОБДП - общую базу данных о предприятии
БАО КТД - бюро автоматической обработки конструкторско - технической документации
ЭВМ - электронная вычислительная машина
КТС - конструкторско-техничекая спецификация
ИИС - интегрированная информационная система
СУБД - система управления базами данных
АРМ - автоматизированное рабочее место
Внедрение на заводе новой CALS-технологии. Одной из частей этой разработки является автоматизация технологии и процессов обработки документов в PDM-системе (разовых заказов, шифров россыпи, служебных записок). В результате внесения изменений в конструкцию изделия, получения сторонних заказов от других предприятий и формирования запасных частей выпускаются служебные записки , разовые заказы и шифры россыпи(РЗ,СЗ,ШР). После изменения изделие отправляется к эксплуатантам.
Данный проект разрабатывается на исходных данных отдела АБД (администратора базы данных состава изделия). Тема диплома реализуется на предприятии ЗАО «Авиастар СП» в 395 отделе.
Цели ставящиеся перед отделом администратора базы данных при разработке новой технологии:
- сокращение финансовых затрат - уменьшение трудоемкости при обработке документации
- сокращение времени обработки информации
- оперативность и качество принимаемых управленческих решений для конструкторов
2. Характеристика объекта автоматизации
Объектом автоматизации является 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
2.Перечень СЗ(детали + материалы + головные СБЕ(сборочных единиц) + стандартные изделия)
3.КТС дополнительных СБЕ(сборочных единиц)
4.КТС раскрытых головных СБЕ(сборочных единиц)
Все эти разделы СЗ формировались вручную на бумажных носителях.
По заявкам сторонних организаций выпускались РЗ(разовые заказы).
Разовые заказы (РЗ) - определяют номенклатуру подлежащую изготовлению по заявкам заказчиков.
Их состав аналогичен СЗ. Кроме того исходя из статистических показателей надежности отдельных деталей и сборок самолета выпускаются запасные части к серийному изделию. Так как они представляют россыпь деталей, сборок (по отношению к целому изделию), то их называют россыпью. Присвоив шифр получают ШР (шифр россыпи). Шифры россыпи (ШР) - определяют изготовление запасных частей россыпью.
Состав СЗ, РЗ, ШР аналогичен. Отличие между ними заключается в нескольких процентах друг от друга по реквизитному составу и алгоритму формирования.
При ручном формировании этих документов технология обработки была простая, но трудоемкая. Все сформированные разделы этих документов на бумаге перфорировались, вводились в БД (база данных) в файлы. К файлам была разработана телеобработка .По изменениям их корректировали в режиме теледоступа.
С развитием БД и увеличением частоты и объема документов СЗ, РЗ, ШР такая технология их обработки имеет большую трудоемкость и большой цикл внедрения. Особенно трудоемким был раздел СЗ по раскрытию состава по всем уровням вхождения головных СБЕ(сборочная единица) из перечня СЗ, то есть разузлования. Поэтому была разработана новая схема СЗ, РЗ,ШР.
2.Перечень СЗ(с указанием обозначения детали, сборочной единицы, серии, количества заказа и цеха потребителя). Остальные реквизиты пустые и подбираются из БД.
3.Лист изменения к серийным КТС, которые вводятся ЭВМ при раскрытии состава головных СБЕ.
5. Раскрытый состав СЗ, РЗ,ШР формируется на ЭВМ. (90% всей трудоемкости занимает этот пункт.)
Особенно трудоемким является последний раздел СЗ, если в него включается тысячи ли десятки тысяч записей. Объем СЗ, РЗ,ШР со временем существенно возрос и составляет 50-60% от серийного объема КТС изделия 204.
Разработанная схема СЗ, РЗ,ШР позволила автоматизировать процесс разработки и формирования данных документов в PDM-системе, на бумажных носителях первых четырех разделов и пятый раздел выполнить на ЭВМ. Состав существующей базы данных.
Существующая PDM-система согласно CALS-технологии представляется общей базой данных об изделии. На предприятии общая база данных об изделии должна содержать разделы: нормативно-справочный, актуальный и долговременный. Но на предприятии на данный момент существует лишь два раздела нормативно-справочный и актуальный.
Интегрированная информационная система представляет собой хранилище данных, содержащее все сведения, создаваемые и используемые всеми подразделениями и службами предприятия - участниками ЖЦ изделия в процессе их производственной деятельности. Это хранилище имеет сложную структуру и многообразные внешние и внутренние связи. ИИС должна включать в свой состав две базы данных: общую базу данных об изделии (изделиях) (ОБДИ) и общую базу данных о предприятии (ОБДП).
Согласно этой схеме в составе ОБДИ можно (условно) выделить три раздела:
В нормативно-справочном разделе должны храниться ИО, содержащие данные:
о нормализованных деталях (нормалях);
о стандартных (покупных) комплектующих изделиях;
о стандартных деталях собственного изготовления; - о стандартных расчетных методах; - о государственных, международных и внутренних стандартах; о прочих нормативных документах.
Содержание нормативно-справочного раздела ОБДИ обновляется по мере поступления новых и отмены действующих нормативных документов.
В долговременном разделе должны храниться ИО, содержащие данные, аккумулирующие собственный опыт предприятия, в том числе данные:
ранее выполненных готовых проектах (архив);
типовых узлах и агрегатах собственного производства;
типовых деталях собственного производства;
типовых конструктивно-технологических элементах (КТЭ) деталей;
типовых и групповых технологических процессах;
типовой технологической оснастке и инструменте;
готовых и типовых расчетных методиках и математических моделях изделий собственной разработки;
Долговременный раздел ОБДИ дополняется и обновляется по мере создания новых технических решений, признанных типовыми и пригодными для дальнейшего использования.
В актуальном разделе (по-видимому, самом большом по объему и самом сложном по структуре) должны храниться ИО, содержащие данные об изделиях, находящихся на различных стадиях ЖЦ:
конструкции и версиях "текущих" изделий;
конкретных экземплярах и партиях изделий в производстве;
конкретных экземплярах и партиях изделий, находящихся на постпроизводственных стадиях ЖЦ.
Кроме ИО, относящихся (прямо или косвенно) к изделиям, в ИИС содержится информация о предприятии: о производственной и управленческой структуре, о технологическом и вспомогательном оборудовании, о персонале, финансах и т.д. Вся совокупность этих данных образует ОБДП, которая, в свою очередь, состоит из нескольких разделов.
В разделе, посвященном экономике и финансам, должны храниться ИО, содержащие сведения:
о конъюнктуре рынка изделий предприятия, включая цены и их динамику;
о состоянии финансовых ресурсов предприятия;
о ситуации на фондовом и финансовом рынках (курсы акций предприятия, биржевые индексы, процентные ставки, валютные курсы и т.д.);
о реальном и прогнозируемом портфеле заказов;
прочие сведения финансово-экономического и бухгалтерского характера.
В разделе, посвященном внешним связям предприятия, должны храниться ИО, содержащие сведения о фактических и возможных поставщиках и потребителях (заказчиках); раздел формируется и используется в процессе маркетинговых исследований.
В разделе, посвященном производственно-технологической среде предприятия, должны храниться ИО, содержащие сведения:
о производственной структуре предприятия;
о технологическом, вспомогательном и контрольно-измерительном оборудовании;
о транспортно-складской системе предприятия;
об энерговооруженности предприятия;
В разделе, посвященном системе качества, должны храниться ИО, содержащие сведения:
о структуре действующей на предприятии системы качества;
о действующих на предприятии стандартах по качеству;
о международных и российских стандартах по качеству;
о должностных инструкциях в области качества;
· прочая информация по системе качества.
На предприятии в данный момент реализованы только Нормативно-справочный и Актуальный разделы. Долговременный раздел находится в бумажном состоянии и почти не используется.
· КТС схем цветовой отделки интерьера изд.204
Бюллетень - документ, определяющий работы по поддержанию и улучшению ТТД и эксплуатационных характеристик, повышение надежности и устранению производственных и конструктивных недостатков авиационной техники
Служебная записка типа «БЛ» - документ, которым запускается бюллетень на предприятии.
Служебная записка типа «СД» - документ, определяющий порядок доработки ВС;
Технологический паспорт - определяющий перечень работ с подтверждением их выполнения;
Технический акт - документ о выполнении работ;
Договор - документ, определяющий объемы доработок по бюллетеням по конкретному заказчику.
Для ведения КТС в состав БДСИ включены в настоящее время следующие первичные документы:
· Конструкторско-технологические спецификации (КТС)
· Перечни перечней и перечни чертежей и спецификаций изд.204
· Листки приостановки изготовления деталей (ПИД)
К перечисленным документам выпускают извещения об изменении (к разовым заказам, с/з УГК, перечням доработок - с/з на изменение). Из них информацию вводят в соответствующие файлы БДСИ в основном в режиме теледоступа.
В отделе администратора баз данных существует старая бумажная технология обработки информации. Бумажная технология характеризуется тем, что конструкторами-технологами вручную заполняются основные конструкторские документы:
- конструкторско-технологические спецификации
Вручную вписанная информация в этих документах перфорируется и вносится в общую базу данных, которая реализована на большой машине. В процессе поступления изменений различных документов информация корректируется и поддерживается в рабочем состоянии . Информацией с большой машины обеспечивает все подразделения предприятия.
- дважды переписывается информация конструктором и оператором
- существующая система работает в пакетном и диалоговом режиме функции которого выполняются отделом АБД
- неразвитая система телеобработки недостаточно развитая(конечный пользователь может только читать информацию из БД)
- много посредников, что увеличивает трудозатраты на обработку КТД.
Такое количество ошибок вынуждает создавать более автоматизированную и модернизируемую информационную систему.
Сейчас в технических СМИ появилось много статей о модуле 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 характерно занесение информации по обозначению в одно поле и использование ссылочного механизма при ведении базы данных состава (запись номера ДСЕ вместо обозначения). Все это приводит к невозможности выполнения сортировок по частям обозначения как по ДСЕ так составу. Это принципиальные недостатки перечисленных систем, которые накладывают много ограничений на дальнейшее использование их информации в других систем. Ведь без сортировок нельзя обойтись, особенно когда номенклатура изделий предприятий составляет сотни тысяч. Теряется информативность, можно легко пропустить при просмотре требующуюся информацию. Все это вынуждает внедрять дополнительные системы, включая собственные. А это ведет к необх
Разработка прикладного программного обеспечения дипломная работа. Программирование, компьютеры и кибернетика.
Как Сделать Реферат По Госту
Курсовая работа по теме Особенности мотивации труда в Республике Беларусь
Гражданский Контроль Эссе
Доклад: Август Вильгельм, герцог Брауншвейг-Бевернский
Разработка Декоративная Решетка В Интерьере Курсовая
Реферат: Персональные данные. Оформление. Обработка. Защита. Скачать бесплатно и без регистрации
Эссе Про Осень
Реферат по теме Аналогии в курсе физики средней школы
Эссе Коллектив
Курсовая работа по теме Реализация политики сетевой безопасности организации средствами маршрутизаторов и коммутаторов CISCO
Темы Курсовых Искусство
Практическая Работа Получение И Распознавание Газов
Курсовая работа по теме Ремонт строительного оборудования
Входная Контрольная Работа По Дисциплине Русский Язык
Дипломная Туберкулез
Курсовая работа по теме Сперанский – великий русский реформатор
Реферат На Тему Формирование Русского Централизованного Государства Россия В Эпоху Ивана Грозного
Лабораторная работа: Организация рабочего пространства по системе 5S на ОАО СУАЛКАЗ-СУАЛ
Команда Эссе
Реферат По Физкультуре Гиподинамия
Система вентиляции Siemens LOGO - Коммуникации, связь, цифровые приборы и радиоэлектроника дипломная работа
Приемник радиовещательный 1 класса - Коммуникации, связь, цифровые приборы и радиоэлектроника курсовая работа
Устройство разделения цифрового потока данных - Коммуникации, связь, цифровые приборы и радиоэлектроника курсовая работа