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

Введение

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

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

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

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

РЗ - разовый заказ

СЗ - служебная записка

ШР - шифр россыпи

АБД - отдел администратора базы данных

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

ОБДИ - общая база данных об изделии

ОБДП - общую базу данных о предприятии

БАО КТД - бюро автоматической обработки конструкторско - технической документации

БДСИ - база данных состава изделия

ЭВМ - электронная вычислительная машина

БД - база данных

СТП - стандарт по выпуску

ИТ - информационные технологии

КТС - конструкторско-техничекая спецификация

СБЕ - сборочных единиц

ИИС - интегрированная информационная система

ЖЦ - жизненных цикл

БЛ - бюллетень

СУБД - система управления базами данных

АРМ - автоматизированное рабочее место

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

.1 Назначение системы

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

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

1.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 (Интермех, РБ) и сравним их с разработкой МЗКТ СпрутМ.

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

БелАЗ промучавшись 7 лет с его внедрением, отказался от закупленных Windchill, BAAN, предпочтя ему Search и старую заводскую систему на Сlipper при их разрозненном использовании. Камнем преткновения явилась проблема синхронизации данных в разных системах построенных по разной бизнес-логике, слишком большой объем вносимой и меняемой информации из-за наличия разных систем, проблема с высококвалифицированными кадрами и разочарование в функционале Windchill и BAAN. Выбор Search был обусловлен, в первую очередь, более низкой ценой и потребностью технологов в модуле Техкард для формирования технологических карт и отсутствием на рынке полноценной PDM. Последний без Search работать не может.является типичной системой электронного документооборота с большей ориентацией и поддержкой Автокада (в других модулях). В версии 9 добавлена поддержка UG, ProE, ведение заказных спецификаций и замен, значительно изменен его интерфейс. Предусмотрено варьирование составом, как на уровне головной сборки, так и внутреннем. Данный пакет лучше вышеперечисленных зарубежных настроен на отечественную систему бумажной конструкторско-технологической документации и документооборот. Обеспечивает формирования и распечатку бумажных документов спецификаций на основе информации баз данных, ведение электронного архива чертежей, согласование. Однако заносимая информация Search все же минимальна: только то, что содержится в штампе чертежа, спецификации и извещении и связанная с заменами и вариациями сборок. Организация электронного архива не в полной мере отвечает современным потребностям производства: файлы сбрасываются в папки, они не кодируются в БД, потом сложно с ними разбираться (различать). ERP-функций у него практически нет. Например, отсутствует функция применяемости. И все это из-за ссылочного механизма ведения состава, не позволяющего вести сортировки. Построить полноценную систему CALS при использовании Search в качестве первичного звена сложно, возникает много проблем по интеграции. Сфера применения Search - проектные организации в основном конструкторско-технологического профиля, которым нет необходимости в CALS. Следует отметить, что Search от версии к версии заметно прогрессирует и по своим возможностям во многом уже превзошел 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-системой, называются цифровым макетом <#"577360.files/image003.gif">

Рис.3 Контекстная диаграмма формирование РЗ,СЗ,ШР

Старая схема загрузки РЗ,СЗ,ШР в БДСИ.

Модель декомпозиции ввода и обработки РЗ, СЗ,ШР первого уровня.

Рис.4 Модель декомпозиции ввода и обработки РЗ, СЗ,ШР первого уровня

Модель декомпозиции раскрытия состава РЗ, СЗ,ШР второго уровня

Рис.5 Модель декомпозиции раскрытия состава РЗ, СЗ,ШР второго уровня

Новая схема ввода и проработки РЗ,СЗ,ШР будет представлена следующей моделью:

Предлагаемая технология обработки информации:

1)      По указанию главного специалиста начинается формирование перечня

РЗ, СЗ, ШР с помощью конструкторов и технологов. Ведется проработка в УГК.

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

3)      Проработка исходных данных и формирование раскрытого массива проводится сотрудниками УГК и УГТ.

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

)        Проработка в УГТ технологами БТП и БНМ

)        Логический контроль АБД РЗ,СЗ,ШР технологами БТП и БНМ (при наличии ошибок возвращается на доработку в УГТ)

)        Централизованная проработка РЗ,СЗ,ШР и проставление подписи технологами УГТ(при наличии ошибок возвращается к формированию)

)        Логический контроль АБД и загрузка в базу утвержденных документов

Администратор АБД переводит в базу утвержденных РЗ,СЗ,ШР.( при наличии ошибок возвращается на проработку в УГТ)

Контекстная диаграмма формирование РЗ,СЗ,ШР

Рис. 6 Контекстная диаграмма формирование РЗ,СЗ,ШР

Диаграмма декомпозиции формирования РЗ, СЗ,ШР

Рис.7 Диаграмма декомпозиции формирования РЗ, СЗ,ШР

По старой схеме работа выполнялась сотрудниками отдела АБД преимущественно в пакетном и диалоговом режиме с многочисленными передачами РЗ,СЗ.ШР между различными исполнителями что приводило к существенным потерям времени.

Новая система включает в себя как старый принцип работы с пока еще существующей бумажной системой работы РЗ, СЗ, ШР так и в новом диалоговом режиме реализующем принцип обработки РЗ,СЗ,ШР по системе workflow. Это позволило устранить недостатки, присутствующие в старой системе. Разработан АРМ (автоматизированное рабочее место) по разработке РЗ,СЗ,ШР.

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

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

При выборе СУБД выборка ведется по четырем интегральным параметрам

производительность обработки

гибкость к изменениям

готовность базы (восстановление при разрушении)

дружественность интерфейса к конечному пользователю и программисту

Сравнивая два существующих СУБД ADABAS 61 и Oracle 8.1 по трем первым параметрам они почти не уступают друг другу, но по четвертому параметру ADABAS существенно проигрывает Oracle.

Использование языка SQL запроса и RAD (быстрая разработка приложения) систем в Oracle создаются приложения любой сложности, которые требуются для конечного пользователя

используя язык SQL запроса есть возможность сортировать в любом виде и реализовывать в любой сложности бизнес процессы

типы данных Blob поля (двоичные данные больших размеров позволяет хранить графическую информацию)

Благодаря всем пунктам система ADABAS была оставлена и заменилась на систему Oracle в PDM-системе.

7.2 Проектирование базы данных

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

Информационное моделирование системы выполняется на основе совокупности моделей, принадлежащих нескольким уровням проектирования. На первом уровне создаётся логическая модель данных, при этом выявляются информационные объекты системы, зависимости между ними, задаются свойства объектов. На втором уровне строится универсальная физическая модель данных. В ней определяется состав и структура таблиц базы данных, основные характеристики полей таблиц. Модели этих двух уровней не зависят от выбранной СУБД. На третьем уровне определяется физическая модель данных, специфичная для выбранной СУБД. При этом могут быть заданы расширенные характеристики таблиц и их полей, описаны дополнительные объекты базы данных.

В данной дипломной работе при обработке РЗ,СЗ,ШР основным объектом является КТC РЗ,СЗ,ШР, поэтому мы строим данную ER-диаграмму.

При данной схеме обработки этих документов логическая схема БД представлена 10 файлами.

СЗ и РЗ в старой схеме содержат следующие файлы:

. Файл перечня

. Изменения КТС(ЛиКТС - лист изменений кострукторско-технологической части)

. Дополнительный КТС.

. Раскрытый состав СЗ, РЗ.

В ШР логическая схема БД представлена пятью файлами:

. Перечень ШР

. ЛиКТС ШР

. Дополнительные КТС.

. Перечень сдаточных позиций ШР.

. Раскрытый состав ШР.

При разработке БД была проведена унификация алгоритмов, графических интерфейсов и способов отображения СЗ, РЗ,ШР на экранах мониторов. Это позволило логическую схему БД по данным документам свести к трем сущностям:

. Сущность КТС документов в СЗ, РЗ, ШР

. Сущность КТС раскрытых сборочных единиц и перечней СЗ, РЗ, ШР.

. Каталог РЗ, СЗ, ШР.

Таблица № 3

№	название сущности	описание
1	KTC RZ,CZ,HR	сведения исходных данных составных частей РЗ,СЗ,ШР(перечня, изменения КТС, дополнительных КТС)
2	RAZZAK	полный раскрытый состав РЗ,СЗ,ШР
3	Каталог РЗ,РЗ,ШР	содержит полный перечень РЗ,СЗ,ШР с момента появления РЗ,СЗ,ШР

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

Для совместного хранения информации этих документов в единой сущности была проведена нормализация информации КТС.

Именно такая классификация позволила хранить информацию исходных данных в структуре КТС и свести разнообразие программного обеспечения к работе с одной таблицей (представлением логическим объединяющим три таблицы в одну) КТС. Алгоритм раскрытия состава сдаточных позиций так же из 10 разновидностей остался один.

Раскрытый файл СЗ, РЗ, ШР так же стал единым. Количество программного обеспечения уменьшилось на порядок, технология существенно упростилась.

Логические связи сущностей

Рис.8 Логические связи сущностей

Связь между этими сущностями ведется по номеру РЗ, СЗ, ШР.

Реляционная схема связи таблиц КТC РЗ,СЗ,ШР Таблица № 4

 

 

 

Схема полного раскрытого состава РЗ,СЗ,ШР. Схема каталога РЗ,СЗ,ШР.

Таблица №5.                                              Таблица №6.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Была проведена нормализация таблицы в результату чего была разделена на взаимосвязанные таблицы.

 

7.2.2 Физическая модель данных

Титульная часть КТС KTCRZCZ_T Таблица № 7

Идентификатор	Формат	Назначение
ID_T НО SP SPO NM IZ SVM SOM KB NI RN VI NP DV VS N L LIT LITI ZV	NUMBER(9) VARCHAR2(30) VARCHAR2(30) VARCHAR2(150) VARCHAR2(100) NUMBER(6) NUMBER(6) NUMBER(6) VARCHAR2(2) VARCHAR2(6) NUMBER(6) VARCHAR2(2) VARCHAR2(30) Date VARCHAR2(2) NUMBER(9) VARCHAR2(6) VARCHAR2(6) NUMBER(9) VARCHAR2(50)	Счетчик Обозначение чертежа Обозначение спецификации Применяется в спецификациях Наименование спецификации (Перечень РЗ.СЗ.ШР) Изделие Серия введения спецификации (Мин.) Серия ограничения спецификации (Мах.) Код КБ на запуск Индекс извещения на запуск Регистрационный номер извещ. на запуск Вид извешения на запуск Код пользователя Дата корректировки Вид спецификации Порядковый № изменения Листов всего Литера Литера индекс Предприятие разработчик документа

Основание раздела 9 КТС KTCRZCZ _9 Таблица № 8

Идентификатор	Формат	Назначение
ID_T OTD OSN	NUMBER(9) NOT NULL NUMBER(3) NOT NULL VARCHAR2(100) NOT NULL

Шифр россыпью по КТС KTCRZCZ_HR Таблица № 9

Идентификатор	Формат	Назначение
ID_T HR	NUMBER(9) NOT NULL NUMBER(11) NOT NULL	Ключ для связи с «Титулом» ШР КТС

Конструкторская часть КТС KTCRZCZ_KC Таблица № 10

Идентификатор	Формат	Назначение
ID_KC ID_T P1 P2 HI HD SV SO S3 S4 KS MA RZ KZ NK FR ZN PZ NMD EI_K MT KO PR_K R9 KB_К NI_К RN_К VI_К NP DV BK IP	NUMBER(9) NOT NULL NUMBER(9) NOT NULL VARCHAR2(1 byte) VARCHAR2(1 byte) VARCHAR2(25 byte) VARCHAR2(25 byte) NUMBER(6) NUMBER(6) NUMBER(6) NUMBER(6) NUMBER(11, 5) NUMBER(11, 5) NUMBER(1) NUMBER(14, 5) NUMBER(1) VARCHAR2(5 byte) VARCHAR2(4 byte) VARCHAR2(3 byte) VARCHAR2(150 byte) VARCHAR2(3 byte) VARCHAR2(150 byte) VARCHAR2(5 byte) VARCHAR2(50 byte) VARCHAR2(3 byte) VARCHAR2(2 byte) VARCHAR2(6 byte) NUMBER(6) VARCHAR2(2 byte) VARCHAR2(30 byte) DATE RAW (16) NUMBER (6)	Счетчик Ключ для связи с «Титулом» Признак корректировки док-та Признак корректировки записи Обозначение исполнения Обозначение детали Серия введения ОКБ Серия ограничения ОКБ Серия введения констр. УГК Серия ограничения констр УГК Кол-во на сборку Масса Раздел спецификации Кол-во на изделие Номер строки Формат Зона Позиция Наименование Ед. измерения конструкторская Материал конструкторский Комплектация Примечание конструкторское Код отдела ввода основания КБ изв.на изменение констр. Индекс изв.на изм.констр. Рег.№ извещения на изм.констр. Вид извещения на изм.констр. Код пользователя БДСИ Дата корректировки Поле модификаций Код изделия строки КТС

Технологическая часть КТС KTCRZCZ_КСT Таблица № 11

Идентификатор	Формат	Назначение
ID_TC ID_KC S1 S2 KM R1 KI NR TP SHR PR_T KB_T NI_T RN_T VI_T NP DV C01-C21 P01-P21 ZP PGO ST KP KL DV NL IL	NUMBER(9) NOT NULL NUMBER(9) NOT NULL NUMBER(6) NUMBER(6) NUMBER(12) VARCHAR2(15 byte) NUMBER(3) NUMBER(11, 5) VARCHAR2(3 byte) NUMBER(11) VARCHAR2(50 byte) VARCHAR2(2 byte) VARCHAR2(6 byte) NUMBER(6) VARCHAR2(2 byte) VARCHAR2(30 byte) DATE NUMBER(3) NUMBER(1) NUMBER(3) NOT NULL NUMBER(1) NUMBER(9) NUMBER(10) NUMBER(10, 5) DATE NUMBER(3) VARCHAR2(1)	Счетчик Ключ для связи с «КС» Серия введения технологическая Серия ограничения техн. Код материала Размер заготовки Единица измерения Норма расхода Тех. индекс ШР (Для РЗ,СЗ код заказа) Примечание технологическое КБ изв.на изм.технол. Индекс извещения на изм.технол. Рег.№ извещения на изм.технол. Вид извещения на изм.технол. Код пользователя БДСИ Дата корректировки Цех-изг 1-21 ПГО 1-21 Цех потребитель ПГО СТК Код подсборки Количество на СТК Дата корректировки Номер листа Доп. индекс листа

Описание записи таблицы исходных данных (сборок и техподсборок) для расчета TZADSBE

Таблица № 12

--------------------------------------------------------------------------------------------

:иденти : Наименование реквизита и значность : тип поля и значность:

:фикатор : в первичном документе : в БД :

-----------------------------------------------------------------------------------------

:RSB1 : Разузловываемая сборка (с 25зн) : Varchar2(25) INDX :

:IZ1 : Код изделия (ц 6 зн.) : Number(6) :

:KOLSB1 : Колич. разузловываемых СБЕ (ц 7 зн) : Number(7) :

:CEX1 : Цех-изготовитель (ц 3 зн.) : Number(3) :

:ST1 : СТК (ц 9 зн.) : Number(9) :

:VPRIM1 : Вид применяемости .(с 1 зн) : Varchar2(1) :

:NSNM1 : Серия вв (ц 6 зн.) : Number(6) :

:NSNMK1: Серия огр. (ц 6зн) : Number(6) :

:SBCVX1 : СБЕ по цепи входимости (с 25 зн.) : Varchar2(25) :

:KZAK1 : Код заказа (ц 8зн) : Number(8) :

:KNK1 : Количество на комплект (ц 6 зн.) : Number(6) :

:PDS1 : Признак сборки (с 1 зн.) : Varchar2(1) :

:PRA1 : Признак аннулирования (с 1 зн.) : Varchar2(1) :

:GSB1 : Головная сборка (сдат.поз.) (с 25 зн) : Varchar2(25) :

:PM1 : Поле модификаций (128 бит) : Raw(16) :

:NBM1 : Номер бита модификации (ц 3 зн) : Number(3) :

:GO1 : Группа опережения (ц 2 зн.) : Number(2) :

:NPR1 : Номер приказания (с 5 зн.) : Varchar2(5) :

:VRZ1 : Вид разузлования (с 2 зн.) : Varchar2(2) :

:VMS1 : Вид формируемого массива (с 1 зн.) : Varchar2(1) :

:ZPR1 : Цех-потребитель с ПГО (ц 3+1зн) : Number(4) :

:SVI1 : Серия вв. изготовления (ц 6 зн.) : Number(6) :

:SOI1 : Серия огр. изготовления (ц 6 зн.) : Number(6) :

:NP : Код пользователя (C 30 зн.) : Varchar2(30) :

:NKART : Номер карт.учета задела (ц 6 зн.) : Number(6) :

:КВ : Код КБ (с 2 зн.) : Varchar2(2) :

:SHR1 : Шифр россыпи (ц 11 зн.) : Number(11) :

:IP1 : Код изделия записи (ц 6 зн.) : Number(6) :

:КO1 : Признак комплектации (ц 2 зн.) : Number(2) :

-------------------------------------------------------------------------------------------

Описание записи таблицы исходных данных (сборок и техподсборок) для расчета TZADSBE1

Таблица № 13

--------------------------------------------------------------------------------------------

:иденти : Наименование реквизита и значность : тип поля и значность:

:фикатор : в первичном документе : в БД :

-------------------------------------------------------------------------------------------

:RSB1 : Разузловываемая сборка (с 25зн) : Varchar2(25) INDX :

:IZ1 : Код изделия (ц 6 зн.) : Number(6) :

:KOLSB1 : Колич. разузловываемых СБЕ (ц 7 зн) : Number(7) :

:VPRIM1 : Вид применяемости .(с 1 зн) : Varchar2(1) :

:NSNM1 : Серия вв (ц 6 зн.) : Number(6) :

:NSNMK1: Серия огр. (ц 6 зн) : Number(6) :

:NCZ1 : № с/з (с 25 зн) : Varchar2(25) :

:PRA1 : Признак аннулирования (с 1 зн.) : Varchar2(1) :

:VRZ1 : Вид разузлования (с 2 зн.) : Varchar2(2) :

:DV1 : Дата : Date :

: NP : Код пользователя (C 30 зн.) : Varchar2(30) :

:КO1 : Признак комплектации (ц 2 зн.) : Number(2) :

:NPR1 : Номер приказания (с 5 зн.) : Varchar2(5) :

:NKART : Номер карт.учета задела (ц 6 зн.) : Number(6) :

:КВ : Код КБ (с 2 зн.) : Varchar2(2) :

-------------------------------------------------------------------------------------------

Описание записи таблицы цепей входимости «дерева сборок» изделия для разузлования TABCVX

Таблица № 14

--------------------------------------------------------------------------------------------

:иденти : Наименование реквизита и значность : тип поля и значность :

:фикатор : в первичном документе : в БД :

-------------------------------------------------------------------------------------------

:GSB4 : Головная сборка (сдат.поз.) (с 25зн) : Varchar2(25) INDX :

:CHTOVX4: Обозначение что входит(с 25 зн) : Varchar2(25) INDX :

:KUDAVX4: Обозначение что входит(с 25 зн) : Varchar2(25) :

:VPRIM4 : Вид применяемости (с 1 зн.) : Varchar2(1) :

: SV4 : Серия вв (ц 6 зн.) : Number(6) :

: SO4 : Серия огр. (ц 6зн) : Number(4) :

: NCZ4 : Номер служебной записки (с 16 зн) : Varchar2(16) :

: KSB4 : Количество на сборку (ц 6+5др.) : Number(11,5) :

: KL4 : Количество на СТК (ц 6+5др.) : Number(11,5) :

: PKP4 : Признак конструк. принадл.(с 3 зн) : Varchar2(3) :

: KIZ4 : Количество на изделие (ц 9+5др.зн) : Number(14,5) :

: KZAK4 : Код заказа (ц 11 зн) : Number(11) :

: KNK4 : Количество на комплект (ц 6 зн.) : Number(6) :

: KODIZ4 : Код изделия (ц 6 зн.) : Number(6) :

: REZ : Резерв (ц 4 зн) : Number(4) :

: PM4 : Поле модификаций (128 бит) : Raw(16) :

: NCVX4 : Номер цепи входим., уровня(ц7+2зн) : Number(9) :

: NUR4 : Номер уровня (ц.3 зн.) : Number(3) :

: GROP4 : Группа опережения (ц 5 зн) : Number(5) :

: PRA4 : Признак аннулирования (с 1 зн.) : Varchar2(1) :

: CEX4 : Цех-изготовитель (ц 3 зн.) : Number(3) :

: ST4 : СТК (ц 9 зн.) : Number(9) :

: VRZ4 : Вид разузлования (с 2 зн.) : Varchar2(2) :

: VMS4 : Вид формируемого массива (с 1 зн.) : Varchar2(1) :

: ZPR4 : Цех-потребитель и ПГО (ц 3 + 1 зн) : Number(4) :

: SVI4 : Серия вв. изготовления (ц 6 зн.) : Number(6) :

: SOI4 : Серия огр. изготовления (ц 6 зн.) : Number(6) :

: STKS : Код СТК сдат.позиции (ц 9 зн.) : Number(9) :

: ZPS : Цех-потреб.сдат.позиции (ц 3 зн.) : Number(3) :

: NBM4 : № бита поля модификации (ц 3 зн.) : Number(3) :

: IP4 : Код изделия записи (ц 6 зн.) : Number(6) :

: NPR4 : № приказания (с 5 зн.) : Varchar2(5) :

: КО4 : Признак комплектации (с 5 зн.) : Varchar2(5) :

:NKART : Номер карт.учета задела (ц 6 зн.) : Number(6) :

:КВ : Код КБ (с 2 зн.) : Varchar2(2) :

-------------------------------------------------------------------------------------------

Описание записи таблицы для выполнения расчетов(сд.позиции и разузлованные СБЕ) KTSRZR

Таблица № 15

--------------------------------------------------------------------------------------------

:иденти : Наименование реквизита и значность : тип поля и значность :

:фикатор: в первичном документе : в БД :

-------------------------------------------------------------------------------------------

: PK :признак корректировки записи(с 1 зн) : Varchar2(1) :

: P3 :Код изделия зад.раскрытия (ц 6 зн.) : Number(6) INDX :

: IB :Код изделия изготов. (ц 6 зн.) : Number(6) :

: ZK :Код заказа (ШР) (ц 11 зн.) : Number(11) INDX :

: GS :Обозначение сдаточной поз.(с 25 зн) : Varchar2(25) INDX :

: HO :Обозначение КТС (с 30 зн.) : Varchar2(25) INDX :

: HI :Обозначение исполнения (с 25 зн.) : Varchar2(25) INDX :

: HD :Обозначение детали (с 25 зн.) : Varchar2(25) INDX :

: KB :Код КБ (с 2 зн.) : Varchar2(2) :

: NI :Индекс изделия изв. (с 6 зн.) : Varchar2(6) :

: RN :Рег.номер извещения (ц 6 зн.) : Number(6) INDX :

: VI :Вид извещения (с 2 зн.) : Varchar2(2) :

: SV :Серия введ.конст. раскр. (ц 6 зн.) : Number(6) :

: SO :Серия огр.конст. раскр. (ц 6 зн.) : Number(6) :

: S1 :Серия введения раскр. (ц 6 зн.) : Number(6) :

: S2 :Серия огранич. раскр. (ц 6 зн.) : Number(6) :

: S3 :Серия введения изг. (ц 6 зн.) : Number(6) :

: S4 :Серия огранич. Изг. (ц 6 зн.) : Number(6) :

: KS :Кол.на сбор.или техподсборку (ц6+5др.зн) : Number(11,5) :

: MA :Масса (ц 6+5др.зн) : Number(11,5) :

: RZ :Раздел КС (ц 1 зн.) : Number(1) INDX :

: KM :Код материала (ц 12 зн.) : Number(12) INDX :

: R1 :Размеры заготовки (с 15 зн.)с : Varchar2(15) :

: KI :Код единицы измерения (ц 3 зн.) : Number(3) :

: NR :Норма расх. мат. (ц 6ц+5др.зн) : Number(11,5) :

: TP :Технологический индекс(с 3 зн.) : Varchar2(3) :

: ST :СТК (ц 9 зн.) : Number (9) INDX :

: KP :Код техподсборки (ц 10 зн.) : Number (10) INDX :

: Z1 :1 цех мар. изг.+ПГО (ц 3зн+2зн) : Number(5) :

: Z2 :2 цех мар. изг.+ПГО (ц 3зн+2зн) : Number(5) :

: Z3 :3 цех мар. изг.+ПГО (ц 3зн+2зн) : Number(5) :

: Z4 :4 цех мар. изг.+ПГО (ц 3зн+2зн) : Number(5) :

: Z5 :5 цех мар. изг.+ПГО (ц 3зн+2зн) : Number(5) :

: Z6 :6 цех мар. изг.+ПГО (ц 3зн+2зн) : Number(5) :

: Z7 :7 цех мар. изг.+ПГО (ц 3зн+2зн) : Number(5) :

: ZP :Цех-потребитель+ПГО (ц 3+2зн) : Number(5) :

: KL :Кол.на СТК расчетное (ц 5+5др.зн) : Number(10,5) :

: КN :Количество на изделие новое (ц 5 зн) : Number(14,5) :

: КК :Количество на комплект (ц 5 зн) : Number(5) :

: KZ :Кол.на сдаточную позицию : Number(14,5) :

: : расчетное (ц 9+5др.зн) : :

: NP :Код пользователя ( с 30 зн.) : Varchar2(30) :

: IZ :Извещение на изменение (с16 зн.) : Varchar2(16) INDX :

: DV :Дата ввода в БД : Date INDX :

: DI :Дата корректировки : Date INDX :

: NU :Номер уровня (ц 2 зн.) : Number(2) :

: RR :Резерв (с 10 зн.) : Varchar2(10) :

: KO :Признак комплектации (с 2 зн.) : Varchar2(2) :

: VD :Вид документа (с 2 зн.) : Varchar2(2) :

: NPR :№ приказания (с 5 зн.) : Varchar2(5) :

: PM :Резерв (с 10 зн.) : Varchar2(10) :

:NKART:Номер карт.учета задела (ц 6 зн.) : Number(6) :

: КВ :Код КБ (с 2 зн.) : Varchar2(2) :

: SТКS :Код СТК сдат.позиции (ц 9 зн.) : Varchar2(10) :

: ZPS :Цех - потреб.сдат.позиции (ц 3 зн.) : Varchar2(10) :

-------------------------------------------------------------------------------------------

Описание записи таблицы для хранения результатов расчета RAZZAK

Таблица № 16

--------------------------------------------------------------------------------------------

:иденти : Наименование реквизита и значность : тип поля и значность :

:фикатор: в первичном документе : в БД :

-------------------------------------------------------------------------------------------

: VD :Вид документа(РЗ,СЗ,ШР) (с 2 зн) : Varchar2(2) INDХ :

: PK :признак корректировки записи(с 1 зн) : Varchar2(1) :

: P3 :Код изделия зад. раскр (ц 6 зн.) : Number(6) INDX :

: IB :Код изделия изгот. (ц 6 зн.) : Number(6) :

: ZK :Код заказа(ШР) (ц 11 зн.) : Number(11) INDX :

: GS :Обозначение сдаточной поз.(с 25 зн) : Varchar2(25) INDX :

: HO :Обозначение КТС (с 30 зн.) : Varchar2(30) INDX :

: HI :Обозначение исполнения (с 25 зн.) : Varchar2(25) INDX :

: HD :Обозначение детали (с 25 зн.) : Varchar2(25) INDX :

: KB :Код КБ (с 2 зн.) : Varchar2(2) :

: NI :Индекс изделия изв. (с 6 зн.) : Varchar2(6) :

: RN :Рег.номер извещения (ц 6 зн.) : Number(6) INDX :

: VI :Вид извещения (с 2 зн.) : Varchar2(2) :

: S1 :Серия введения раскр. (ц 6 зн.) : Number(6) :

: S2 :Серия огранич. раскр. (ц 6 зн.) : Number(6) :

: S3 :Серия введения изг. (ц 6 зн.) : Number(6) :

: S4 :Серия огранич. изг. (ц 6 зн.) : Number(6) :

: KS :Кол.на сбор.или техподсбор. (ц6+5др.зн) : Number(11,5) :

: MA :Масса (ц 6+5др.зн) : Number(11,5) :

: RZ :Раздел КС (ц 1 зн.) : Number(1) INDX :

: KM :Код материала (ц 12 зн.) : Number(12) INDX :

: R1 :Размеры заготовки (с 15 зн.) : Varchar2(15) :

: KI :Код единицы измерения (ц 3 зн.) : Number(3) :

: NR :Норма расх. мат. (ц 6ц+5др.зн) : Number(11,5) :

: TP :Технологический индекс(с 3 зн.) : Varchar2(3) :

: ST :СТК (ц 9 зн.) : Number (9) INDX :

: KP :Код техподсборки (ц 10 зн.) : Number (10) INDX :

: Z1 :1 цех мар. изг.+ПГО (ц 3зн+2зн) : Number(5) :

: Z2 :2 цех мар. изг.+ПГО (ц 3зн+2зн) : Number(5) :

: Z3 :3 цех мар. изг.+ПГО (ц 3зн+2зн) : Number(5) :

: Z4 :4 цех мар. изг.+ПГО (ц 3зн+2зн) : Number(5) :

: Z5 :5 цех мар. изг.+ПГО (ц 3зн+2зн) : Number(5) :

: Z6 :6 цех мар. изг.+ПГО (ц 3зн+2зн) : Number(5) :

: Z7 :7 цех мар. изг.+ПГО (ц 3зн+2зн) : Number(5) :

: ZP :Цех-потребитель+ПГО (ц 3+2зн) : Number(5) :

: KZ :Кол.на сдаточную позицию : Number(14,5) :

: : расчетное (ц 9+5др.зн) : :

: KL :Кол.на СТК расчетное (ц 5+5др.зн) : Number(10,5) :

: КК :Количество на комплект (ц 5 зн) : Number(5) :

: NP :Код пользователя ( с 30 зн.) : Varchar2(30) :

: IZ :Извещение на изменении (с16 зн.) : Varchar2(16) INDX :

: DV :Дата ввода в БД : Date INDX :

: DI :Дата корректировки : Date INDX :

: NU :Номер уровня (ц 2 зн.) : Number(2) :

: RR :Резерв (с 10 зн.) : Varchar2(10) :

: NPR :№ приказания (с 5 зн.) : Varchar2(5) :

:NKART : Номер карт.учета задела (ц 6 зн.) : Number(6) :

:КВ : Код КБ (с 2 зн.) : Varchar2(2) :

-------------------------------------------------------------------------------------------

Описание записи таблицы для хранения каталога РЗ, СЗ, ШР KATSZRZ

Таблица № 17

--------------------------------------------------------------------------------------------

:иденти : Наименование реквизита и значность :тип поля и значность :

:фикатор: в первичном документе : в БД :

-------------------------------------------------- ----------------------------------------

: VD :Вид документа(РЗ,СЗ,ШР) (с 2 зн) : Varchar2(2) IND :

: KOD :Код подразд., выпустившего С/З(ц 3 зн.) : Number(3) INDX :

: KB :Код КБ (с 2 зн.) : Varchar2(2) :

: NI :Индекс изделия изв. (с 6 зн.) : Varchar2(6) :

: RN :Рег.номер извещения (ц 6 зн.) : Number(6) INDX :

: VI :Вид извещения (с 2 зн.) : Varchar2(2) :

: SR :Шифр россыпи (ц 11 зн.) : Number(11) :

: KO :Признак комплектации (с 5 зн.) : Varchar2(5) :

: DV :Дата ввода в БД (при запуске КД) : Date INDX :

: DI :Дата изменения : Date INDX :

: NS :Номер извещения на измен. (с 16 зн.) : Varchar2(16) :

: PD :Признак действия С/З ( с 1 зн.) : Varchar2(1) :

: PG :Признак гашения С/З ( с 1 зн.) : Varchar2(1) :

: OZ :Основание запуска С/З ( с 200 зн.) : Varchar2(200) :

: NP :Код пользователя (с 30 зн.) : Varchar2(30) :

-------------------------------------------------------------------------------------------

Описание записи таблицы «Массив плановых машин» PLANM

Таблица № 18

--------------------------------------------------------------------------------------------

:иденти : Наименование реквизита и значность :тип поля и значность :

:фикатор: в первичном документе : в БД :

-------------------------------------------------- ----------------------------------------

: P1 : Признак корректировки : Varchar2(1) :

: P3 : Код изделия : Number(6) INDX :

: SP : Cерия плановой машины : Number(6) :

: DV : Дата ввода в БД : Date INDX :

: NP : Код пользователя (с 30 зн.) : Varchar2(30) :

-------------------------------------------------------------------------------------------

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

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

Запуск служебных записок УГК в электронном виде.

В целях обеспечения разработки автоматизированного рабочего места (АРМ) конструктора УГК и технолога УГТ по запуску служебных записок УГК в электронном виде, принимается следующий порядок оформления и проработки конструкторских служебных записок:

Предлагаемая технология обработки информации:

1.   По указанию главного специалиста начинается формирование перечня

РЗ, СЗ, ШР с помощью конструкторов и технологов. Ведется проработка в УГК.

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

3.       Проработка исходных данных и формирование раскрытого массива проводится сотрудниками УГК и УГТ.

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

.        Проработка в УГТ технологами БТП и БНМ

.        Логический контроль АБД РЗ,СЗ,ШР технологами БТП и БНМ (при наличии ошибок возвращается на доработку в УГТ)

.        Централизованная проработка РЗ,СЗ,ШР и проставление подписи технологами УГТ(при наличии ошибок возвращается к формированию)

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

Администратор АБД переводит в базу утвержденных РЗ,СЗ,ШР.( при наличии ошибок возвращается на проработку в УГТ)

8. Математическое обеспечение системы

Математическое обеспечение представлено следующими алгоритмами:

Алгоритм конвертирования данных РЗ,СЗ,ЩР из старой системы в новую

В данном алгоритме входными данными являются файлы КТС1 КТС2.КТС3,КТС4 RAZZAK выгружается в последовательный текстовый файл.

Читается на большой ЭВМ и распаковывается.

Алгоритм ввода и корректировки данных РЗ, СЗ. ШР

Проводится подготовка данных бумажного документа. И формируется последовательный текстовый файл который передается с ГАРМ на сервер ПК. Затем запускается проект ввода текстового файла KTCRZ и проводится загрузка БД (Oracle).

Алгоритм ввода РЗ,СЗ,ШР (исходных данных) в режиме телеобработки

Задается номер служебной записки , шифр затрат, код изделия, вид исходных данных. Затем на экране в таблицу вводится информация с исходных данных и записывается в базу в таблицу KTC RZ..

Алгоритм раскрытия и формирования РЗ, СЗ, ШР

Создать входную таблицу служебных записок(СЗ) с заданными РЗ,СЗ,ШР для выполнения раскрытия СБЕ. (Пункт панели «Создать вх. таблицу»)

Пользователь заносит один номер РЗ,СЗ,ШР, для которого он хочет раскрыть состав перечня заданного документа.

По заданным заданной СЗ,РЗ,ШР формируют список СБЕ подлежащий разузлованию (Будет далее проведено раскрытие состава СБЕ по всем уровням входимости) (пункт панели «Создать таблицу для разузлования»).

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

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

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

После создания списка СБЕ для раскрытия приступают к их разузлованию.

Пункт меню «Сформировать РЗ,СЗ,ШР»

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

В некоторых случаях СБЕ для раскрытия могут отсутствовать.

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

После разузлования СБЕ по дополнительным КТС проводится автоматически повторное разузлованике СБЕ серийных КТС (если таковые имеются в списке СБЕ). Аннулируемые СБЕ заносятся в таблицу ОП ПК.

При выполнении разузлования формируется цепочка входимостей СБЕ по всем уровням. Вдоль цепочки перемножаются реквизит К колб на сбi с учетом пересечения серии, поля модификаций и вычисляется применяемость На сдаточную позицию.

При выполнении разузлования цепочка входимостей СБЕ на аннулируемой СБЕ разрывается (что приводит к удалению аннулируемой СБЕ и всех ниже входящих в нее сборок. Результат вычислений заносится в таблицу применяемости сборок, которая после сортируется и затем суммируется.

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

Ксдп = Ксбе * Кол. на сб.

При вычислении полной применяемости проводится ряд дополнительных вычислений.

для СБЕ общей части по исполнению, в которое входит общая часть, определяется состав техподсборок, входящих в это исполнение.

Для сдаточных техподсборок вычисляется их количестово с учетом СТК, пересечения серий и поля модификаций.

Затем читается каждая позиция с учетом пересечения серий и поля модификаций (для семейства изделий 7400). Для прочих изделий проверяется равенство кода изделия со входа и БД.

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

«Было-Стало» и аннулируемых деталей. Если позиция аннулируется, то она будет пропущена, т.е. удаляется из расчета, если изменяется, то в этой позиции будут изменены некоторые реквизиты.

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

При упаковке в таблицу:

вычисляется группа опережения по маршруту;

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

для 5-го раздела (стандартных изделий ) из КТСУСД подсоединяются технологические реквизиты;

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

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

вычисление количества на сдаточную позицию

Ксдп = Ксбе * К кол.на сб

(для раздела 2,3,4,5,6,8) для конструкторской СБЕ со входа)

Для техподсборки со входа

К кол.на сб = koldet / koltp;

Ксдп = Ксбе * К кол.на сб

koldet - количество по СТК по детали- количество по СТК техподсборки со входа.

определение старшей серии с учетом техподсборки в первом младшем интервале

подсчет группы опережения в выходной записи

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

распределение количество на сдаточную позицию по старой пропорции СТК, имеющейся в БД вычислить количество на исполнение нормы расхода для 7-го раздела для деталей (раздел КТС 4) раскрыть цветовую схему

алгоритм одиночной корректировки RAZZAK

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

алгоритм групповой корректировка RAZZAK

Запускается проект с вызовом соответствующей служебной записке с вызовом соответствующей служебной записки и задают исходные данные по корректировке (было и стало).Например задают маршрут движение детали старой и маршрут движения детали новой и нажимают кнопку выполнить. Происходит замена старой информации на новую в БД. После окончания работы выдается счетчик количества откорректированных записей.

9. Программное обеспечение системы

.1 Операционная система

На предприятии Авиастар - СП уже установлена операционная система Windows 2000, основываясь на этих данных выбрана эта ОС.

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

++BuilderX создана специально для решения комплексных IT задач больших предприятий. В этой среде разработчикам будут доступны высокопроизводительные драйверы для распространенных корпоративных баз данных, средства настройки для повышения производительности приложений, а также интеграция с CORBA - всё это поможет специалистам быстрее создавать профессиональные, конкурентоспособные корпоративные системы. Использование C++BuilderX значительно снижает затраты на IT-инфраструктуру, так как гибкость этой среды позволяет переносить приложения, созданные на C++, на различные платформы.

Основные преимущества Borland C++BuilderX

Позволяет в рамках унифицированной среды перенести разработку на языке C++ на различные платформы.

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

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

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

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

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

Усилия по координации проекта могут столкнуться со значительными трудностями в коммуникации при попытке удержания информационных ресурсов проекта на уровне современных требований и обеспечения их доступности для всех членов проектной группы. Усовершенствованные технологии командной продуктивности и эффективности могут увеличить производительность разработчиков, включая большие группы или те группы, члены которых работают на различных платформах. C++BuilderX предназначен для упрощения параллельного управления исходным кодом за счет тесной интеграции с Borland StarTeam - системы автоматического конфигурирования и управления изменениями, а также с системой контроля параллельных версий CVS (Concurrent Versions System), Rational ClearCase и Microsoft Visual SourceSafe. При создании C++BuilderX особое внимание уделялось увеличению групповой координированности и снижению количества ошибок. Эта среда позволяет группам разработки наглядно проводить обновления и разрешать конфликты рабочих версий путем согласования изменений между рабочим пространством и репозиторием.

Язык С++++ (Си++) - компилируемый статически типизированный язык программирования общего назначения. Поддерживает разные парадигмы программирования, но, в сравнении с его предшественником - языком Си, - наибольшее внимание уделено поддержке объектно-ориентированного и обобщённого программирования.

Нововведениями C++ в сравнении с Си являются:

поддержка объектно-ориентированного программирования;

поддержка обобщённого программирования через шаблоны;

дополнительные типы данных;

исключения;

пространства имён;

встраиваемые функции;

перегрузка операторов;

перегрузка имён функций;

ссылки и операторы управления свободно распределяемой памятью;

дополнения к стандартной библиотеке.

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

.3.1 Ввод РЗ,СЗ,ШР из текстового файла

Рис.9 Алгоритм ввода РЗ,СЗ,ШР из текстового файла

1. Открытие текстового файла

. Цикл чтения текстового файла

.1 Чтение записи

.2 Перекодировка из DOS в Widows

.3 Распаковка реквизитов отдельных записей

.4 Очистка запросов

,5 Сформировать вид части РЗ, ШР,СЗ (перечень, изменения КТС или дополнительная КТС)

.6 Проверка есть ли в таблице такой СЗ,РЗ,ШР если есть то удаляется

.7 Сформировать реквизит для каждого раздела

.8 Ввести в КТС конструкторские и технологические записи

.9 Проверка есть ли изменения в КТС титул если есть удаляет запись

.10 Вписать строчку в каталог

Рис.10. Ввод СЗ,РЗ,ШР в БДЭОИ.

9.3.2 Просмотр и корректировка перечня РЗ,СЗ,ШР

1. Задает номер СЗ,РЗ,ШР на панели и код заказа

. Жмет кнопку выполнить запрос

. По исходным данным считывается информация

. Информация отображается в окне отображения (DBGrid)

. Пользователь находит соответствующую строку и корректирует

. Информация сразу же вносится в БД

. После внесения изменений пользователь жмет кнопку закрыть

Рис.11. Алгоритм просмотра и корректировки перечня РЗ,СЗ,ШР

Рис.12 Просмотр и корректировка перечня РЗ,СЗ,ШР

9.3.3 Раскрытие состава РЗ,СЗ,ШР

Рис.13 Раскрытие состава РЗ,СЗ,ШР

9.3.4 Корректировка применяемости раскрытых СЗ,РЗ,ШР

Рис.14 Корректировка применяемости раскрытых СЗ,РЗ,ШР.

10. Тестирование системы

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

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

Тестирование направлено на оценку и обеспечение качества создаваемых компонентов и всей системы. В процессе тестирования решаются следующие задачи:

• поиск и документирование дефектов качества;

• формирование общих рекомендаций относительно качества;

• проверка выполнения основных требований на конкретных примерах;

• проверка, что продукт функционирует так, как было запроектировано;

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

• устранение найденных дефектов.

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

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

Процесс отладки включает: выявление ошибки; определение сущности и местонахождения предполагаемой ошибки в рамках программы; устранение обнаруженной ошибки.

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

Рис. 15 Типы тестов и их связь с этапами жизненного цикла КИС

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

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

• тесты сопряжения, или интегральное тестирование, направлены на контроль сопряжения между отдельными модулями;

• тестирование внешних функций направлено на контроль внешнего поведения системы модулей, определенных внешними спецификациями;

• комплексное (системное) тестирование - контроль и испытание системы по отношению к исходным целям. Комплексное тестирование является процессом контроля, если оно выполняется в моделируемой среде, и процессом испытания, если выполняется в реальной аппаратно-программной среде в условиях действующей локальной сети;

• тестирование приемлемости - проверка соответствия КИС информационным потребностям пользователей.

10.1 Перечень объектов тестирования

Ввод РЗ,СЗ,ШР из текстового файла

Произведен комплексный уровень тестирования

Последовательность произведенных операций

Тип проверки -автоматизированный

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

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

11.1 Безопасность жизнедеятельности

К самостоятельной работе на персональном компьютере допускаются лица, прошедшие:

Предварительный медицинский осмотр. К непосредственной работе с персональным компьютером допускаются лица, не имеющие медицинских противопоказаний. Женщины со времени установления срока беременности и в период кормления ребенка грудью к выполнению видов работ, связанных с использованием персонального компьютера не допускаются.

Первичный инструктаж на рабочем месте и имеющие квалификационную группу по электробезопасности.

Опасными и вредными производственными факторами при выполнении работ на персональном компьютере являются:

Физические:

- повышенные уровни электромагнитного излучения;

- повышенные уровни рентгеновского излучения;

- повышенные уровни ультрафиолетового излучения;

- повышенный уровень инфракрасного излучения;

- повышенный уровень статического электричества;

- повышенные уровни запыленности воздуха рабочей зоны;

- повышенное содержание положительных аэроионов рабочей зоны;

- пониженное содержание отрицательных аэроионов рабочей зоны;

- пониженная или повышенная влажность воздуха рабочей зоны;

пониженная или повышенная подвижность воздуха рабочей зоны;

повышенный уровень шума;

повышенный или пониженный уровень освещенности;

повышенный уровень прямой блесткости;

повышенный уровень отраженной блесткости;

повышенный уровень ослепленности;

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

повышенная яркость светового изображения;

- повышенный уровень пульсации светового потока;

- повышенное значение напряжения в электрической сети, замыкание которой может пройти через тело человека.

Химические:

 повышенное содержание в воздухе рабочей зоны двуокиси углерода, озона, аммиака, фенола, формальдегида и полифинных бифенилов.

Психо-физические:

напряжение зрения;

напряжение внимания;

интеллектуальные нагрузки;

эмоциональные нагрузки;

длительные статические нагрузки;

монотонность труда;

большой объем информации, обрабатываемой в единицу времени;

нерациональная организация рабочего места.

Биологические:

- повышенное содержание в воздухе рабочей зоны микроорганизмов.

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

Площадь на одно рабочее место с персональным компьютером для взрослых пользователей должна составлять не менее 6 м., а объем - не менее 24 м .

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

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

Схемы размещения рабочих мест с персональным компьютером должны учитывать расстояния между рабочими столами с видеомониторами (в направлении тыла поверхности одного видеомонитора и экрана другого видеомонитора), которое должно быть не менее 2 м., а расстояние между боковыми поверхностями видеомониторов не менее 1,2 м.

Экран видеомонитора должен находиться от глаз пользователя на оптимальном расстоянии 600-700 мм, но не ближе 500 мм, с учетом размеров алфавитно-цифровых знаков и символов.

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

Помещения с персональным компьютером должны быть оснащены аптечкой первой помощи и углекислотными огнетушителями.

Высота рабочей поверхности стола для взрослых пользователей должна регулироваться в пределах 68О-800 мм; при отсутствии такой возможности высота рабочей поверхности стола должна составлять 725 мм.

Рабочее место с персональным компьютером должно быть оснащено легко перемещаемым пюпитром для документов.

Клавиатуру следует располагать на поверхности стола на расстоянии от 100 мм до 300 мм от края, обращенного к пользователю, или на специальной регулируемой по высоте рабочей поверхности, отдельно от основной, столешнице.

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

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

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

Виды трудовой деятельности разделяются на 3 группы:

- группа А - работа по считыванию информации с экрана ПЭВМ с предварительным запросом;

- группа Б - работа по вводу информации;

- группа В - творческая работа в режиме диалога с ЭВМ.

Для видов трудовой деятельности устанавливается 3 категории тяжести и напряженности работы с ПЭВМ, которые определяются:

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

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

- для группы В - по суммарному времени непосредственной работы с ПЭВМ за рабочую смену, но не болев 6 часов за смену.

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

 

11.2 Требования перед началом работ

Перед началом работы:

Осмотреть и привести в порядок рабочее место.

Отрегулировать освещенность на рабочем месте, убедиться в достаточной освещенности, отсутствии отражений на экране, отсутствии встречного светового потока.

Проверить правильность подключения оборудования к электросети.

Убедиться в наличии защитного заземления и подключения экранного проводника к корпусу процессора.

Протереть специальной салфеткой поверхность.

Убедиться в отсутствии дискет в дисководах процессора персонального компьютера.

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

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

- включить блок питания;

- включить периферийные устройства (принтер, монитор, сканер и др.);

 включить системный блок (процессор).

Запрещается приступать к работе при:

Обнаружении неисправности оборудования.

Отсутствии защитного заземления устройства ПЭВМ;

Отсутствии углекислотного или порошкового огнетушителя и аптечки первой помощи.

Нарушении гигиенических норм размещения ПЭВМ (при однорядном расположении менее 1 м от стен, при расположении рабочих мест в колонну на расстоянии менее 1,5 м, при размещении на площади менее 6 м на одно рабочее место, при рядном размещении дисплеев экранами друг к другу).

Для уменьшения воздействия вредных Факторов рекомендуется:

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

Исключить блики на экране.

Не пользоваться люминесцентными лампами, если вы замечаете их мигание.

Стена или какая-либо поверхность позади дисплея должна быть освещена примерно также как экран.

Предпочтительнее использовать жидкокристаллический дисплей.

Расстояние от расположенных рядом терминалов должно быть не менее 1,2 м.

Центр изображения на дисплее должен находиться на высоте 0,7-1,2 м от уровня пола.

Осмотреть рабочее место и убрать посторонние предметы.

 

11.3 Требования безопасности во время работы

Во время работы:

Выполнять только ту работу, которая была поручена и по которой проинструктирован.

Содержать в порядке и чистоте рабочее место.

Держать открытым все вентиляционные отверстия устройств.

Внешнее устройство "мышь" применять только при наличии специального коврика.

При необходимости прекращения работы на некоторое время корректно закрыть все активные задачи.

Отключить питание только в том случае, если пользователь во время перерыва в работе на компьютере вынужден находиться в непосредственной близости от видеотерминала (менее 2 м), в противном случае питание разрешается не отключать.

Выполнять санитарные нормы и соблюдать режимы работы и отдыха.

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

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

Соблюдать расстояние от глаз до экрана в пределах 60-80 см.

Во время работы ЗАПРЕЩАЕТСЯ:

Касаться одновременно экрана монитора и клавиатуры.

Прикасаться к задней панели системного блока (процессора) при включенном питании.

Переключение разъемов интерфейсных периферийных устройств, при включенном питании.

Загромождать верхние панели устройств бумагами и посторонними предметами.

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

Производить отключение питания во время выполнения активной задачи.

Производить частые переключения питания.

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

Включать сильно охлажденное (принесенное с улицы в зимнее время) оборудование.

Производить самостоятельно вскрытие и ремонт оборудования.

Превышать количество обрабатываемых символов 30 тыс. за 4 часа работы.

Одним из многочисленных режимов работы является:

Для пользователей ПЭВМ 40-45 мин. работы на компьютере и 15-20 мин. перерыв.

Для учащихся средних и высших учебных заведений:

- для студентов первого курса - 1 час;

- для студентов старших курсов - 2 часа с обязательным соблюдением между двумя академическими часами занятий перерыва длительностью 15-20 мин. Допускается время учебных занятий с ПЭВМ увеличивать для студентов первого курса до 2 часов, а для студентов старших курсов до 3 академических часов, при условии, что длительность учебных занятий в дисплейном классе (аудитории) не превышает 50% времени непосредственной работы на ПЭВМ и при соблюдении профилактических мероприятий: упражнения для глаз, физкультминутка и физкультпауза. Проведение упражнений для глаз проводить через каждые 20-25 минут работы за ПЭВМ.

Проводить во время перерывов сквозное проветривание помещения с ПЭВМ с обязательным выходом студентов из него.

Продолжительность непрерывной работы с ПЭВМ без регламентированного перерыва не должна превышать 2 часов.

При работе с ПЭВМ в ночную смену (с 22 до 6 часов), независимо от категории и вида трудовой деятельности, продолжительность регламентированных перерывов должна увеличиваться на 60 минут.

При 8-ми часовой рабочей смене и работе на ПЭВМ регламентированные перерывы следует устанавливать:

-   для I категории работ через 2 часа от начала рабочей смены и через 2 часа после обеденного перерыва продолжительностью 15 минут каждый;

-        для 2 категории работ через 2 часа от начала рабочей смены и через 1,5-2,0 часа после обеденного перерыва продолжительностью 15 минут каждый или продолжительностью 10 минут через каждый час работы;

-        для 3 категории работ через 1,5-2,0 часа от начала рабочей смены и через 1,5-2,0 часа после обеденного перерыва продолжительностью 15 минут через каждый час работы;

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

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

 

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

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

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

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

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

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

В случае отключения электропитания прекратить работу и сообщить руководителю о случившемся. Не пытаться самостоятельно выяснять и устранять причину. Помнить, что напряжение может так же неожиданно появиться.

11.5 Требования безопасности по окончании работы

По окончании работ соблюдать следующую последовательность выключения вычислительной техники:

Произвести закрытие всех активных задач.

Убедиться, что в дисководах нет дискет.

Выключить питание системного блока.

Выключить питание всех периферийных устройств.

Отключить блок питания.

Осмотреть и привести в порядок рабочее место. Вымыть с мылом руки и лицо.

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

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

 

11.6 Мероприятия по обеспечению безопасности и безвредных условий труда

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

Таблица 4.1 Опасные и вредные производственные факторы

Факторы	Наименование параметра	Допустимые значения	Мероприятия по снижению
Физические	Нарушение норм микроклимата	Температура 21-25 0С, Относительная влажность - 40% - 60% Скорость движения воздуха - не более 0,1 м/с	Влажная уборка, применение кондиционеров, умеренное использование дополнительных обогревателей, проветривание помещений
	Недостаточная освещенность	На рабочем месте - 100-250 лк Стола - 300-500 лк Яркость экрана не менее 35 кд/м2	- Своевременная замена перегоревших ламп; - Использование люминисцентных ламп типа ЛБ.
	Повышенный уровень шума на рабочем месте	Не более 60 дБ	Снижение звуковой мощности источника шума; ориентация направленности излучения шума; экранирование источников шума; средства индивидуальной защиты.
Химические	Химические вещества, выделяемые при работе принтеров, мониторов и копировальной техники
Психофизиологические	Напряжение зрения - монитор от глаз на расстоянии не менее:	600-700 мм	Работа с перерывами, предусматривающими гимнастику для глаз
	Напряжение внимания		Перерывы, обеспечивающие смену вида деятельности
	Длительные статические нагрузки		Обеспечение возможности активного отдыха во время перерывов
	Монотонность труда		Чередование операций осмысленного текста и числовых данных (изменение содержания работ); Чередование редактирования текстов и ввода данных (изменение содержания работы);

 

11.7 Расчет освещенности

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

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

Рассматриваемое помещение имеет следующие характеристики:

­   Высота - 4 м;

­    Ширина - 6 м;

­    Длина - 9 м.

Определим расчетный световой поток, лм(люмен), группы светильников:

Е - нормированная минимальная освещенность, лк(люкс) (для рассматриваемой работы Е = 300 лк);- площадь освещаемого помещения, м2;- коэффициент минимальной освещенности (для ЛЛ Z = 1.1);

К - коэффициент запаса (для рассматриваемого помещения К = 1.5);- коэффициент использования светового потока ламп.

Значение n определим по таблице коэффициентов использования различных светильников. Для этого вычислим индекс помещения по формуле

Согласно индексу помещения его показатель равен 1, а n - 0.3.

Подставим значения в формулу для определения светового потока F:

Для освещения будем использовать энергосберегающие лампы LED-T8SE-150. Их параметры: длина - 1200 мм, диаметр - 30 мм, световой поток Fл = 1900 лм.

Рассчитаем необходимое количество ламп по формуле:

- необходимое количество ламп;л- световой поток лампы.

 (шт.)

Для достижения равномерной горизонтальной освещенности светильники с 2 лампами располагаются так, как представлено на рисунке: сплошными рядами, параллельными стенам с окнами в два ряда, по четыре светильника в каждом ряду.

Рис. 4.1 Распределение светильников по площади помещения.

 

11.8 Расчет вентиляции

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

Рассматриваемое помещение имеет следующие характеристики:

­    Высота - 4 м;

­    Ширина - 9 м;

­    Длина - 6 м.

Определим расход приточного воздуха, м3/ч, необходимый для отвода избыточной теплоты:

Qизб - избыточная количество теплоты, кДж/ч;

С - теплоемкость воздуха, Дж/(кг*К); с=1,2 кДж/(к*К);

ρ - плотность воздуха, кг/м3;

tуд - температура воздуха, удаляемого из помещения, 0С; tуд = 25 0С;

tпр - температура приточного воздуха, 0С; tпр = 22 0С.

Рассчитаем плотность воздуха, поступающего в помещение:

 (кг/м3)

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

Qр - теплота, выделяемая работающим персоналом, кДж/ч;

n - число работающих, чел.;

Кр - теплота, выделяемая одним человеком, кДж/ч (при легкой работе равна 100 кДж/ч).

 (кДж/ч)

Таким образом, расход приточного воздуха составит:

 (м3/ч)

Рассчитаем кратность воздуха, 1/ч:

Vc - внутренний свободный объем помещения, м3.

 (1/ч)

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

 

11.9 Расчет мощности кондиционера

Чтобы правильно рассчитать кондиционер необходимо учитывать ряд параметров:

. Площадь помещения

. Высота потолка

. Площадь остекления

. Сторона света (Юг, Запад и т.д.)

. Кол-во человек находящихся в помещении

. Кол-во оргтехники (компьютер, телевизор и т.д.)

. Назначение помещения

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

Учет теплопритоков для расчета необходимой мощности:

·        Сначала рассчитываем Q1 - теплопритоки помещения: Q1 = S*h*g, где S - площадь помещения, h - высота потолка, g - коэффициент тепловой нагрузки:= 30 - если не солнечная сторона. g = 35 - среднее значение

g = 40 - солнечная сторона;

·        К полученному результату необходимо прибавить Q2 - теплопритоки, исходящие от людей находящихся в помещении:

Вт - на 1 спокойно движущегося человека

Вт - на 1 активно движущегося человека (спортзал)

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

·        И также прибавить Q3 - теплопритоки от оргтехники:

Вт - на 1 компьютер (в полной комплектации), телевизор

затем теплопритоки необходимо умножить на кол-во единиц оргтехники.

Общая мощность рассчитывается из суммы всех теплопритоков:

общ = Q1+Q2+Q3

Данные:

Площадь помещения: S=54 м2.

Высота потолка: h=4 м.

Коэффициент тепловой нагрузки: g=35.

Кол-во человек: 7.

Кол-во оргтехники: 6 компьютеров.

Расчет:

Q1=54*4*35=7560 Вт

Q2=100*7=700 Вт

Q3=300*6=1800 Вт

Qобщ=7560+700+1800=10060 Вт или 10.06 кВт.

Мощность кондиционера для заданных параметров помещения должна составлять не менее 10.06 кВт.

Вывод

В данном разделе «Экология и безопасность жизнедеятельности» дипломного проекта были проанализированы вредные и опасные производственные факторы, оказывающие влияние на пользователя ПК и предложены мероприятия по устранению и снижению такого влияния, а также приведена инструкция по технике безопасности при работе на компьютере. Также была рассчитана освещенность и вентиляция. Согласно расчетам, для освещения рассматриваемого помещения были предложены энергосберегающие лампы типа LED-T8SE-150. В качестве системы вентиляции наиболее подходит кондиционер, так как он автоматически поддерживает в помещении заранее заданные микроклиматические условия (температура, влажность, подвижность воздуха). Для данного помещения мощность кондиционера должна составлять не менее 10.06 кВт. Рекомендуемый кондиционер для помещения WindAir WFH-367BE/WUH-R367BE.

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

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

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

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

сокращение расхода машинного времени и других ресурсов на отладку и сдачу задач в эксплуатацию;

повышение технического уровня, качества и объемов вычислительных работ;

увеличение объемов и сокращение сроков переработки информации;

повышение коэффициента использования вычислительных ресурсов, средств подготовки и передачи информации;

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

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

снижение затрат на эксплуатационные материалы.

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

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

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

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

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

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

Гарантированный экономический эффект рассчитывается в виде гарантированного экономического эффекта для конкретного объекта внедрения и общего гарантированного внедрения по ряду объектов.

Гарантированный экономический эффект для конкретного объекта внедрения рассчитывается после окончания разработки для одного внедрения программы на основе данных о гарантированном разработчиком удельном эффекте от применения программного изделия и гарантированных пользователем сроках и годовом объеме использования программного изделия. Гарантированный эффект от одного внедрения программного изделия рассчитывается при оформлении договорных отношений между организацией-разработчиком и организацией-пользователем.

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

Показатели экономической эффективности изделия определяются:

- экономической оценкой результатов влияния программного изделия на конечный результат их использования (основное направление анализа и расчета показателей эффективности - для прикладных программных изделий);

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

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

Для расчета экономической эффективности проекта произведем предварительные расчеты.

 

12.1 Расчет себестоимости программы

Исходные данные для расчета представлены в таблице 5.1 и 5.2.

Данные для расчета себестоимости программы Таблица 5.1

Наименование показателя	Ед. изм	Обозначение	Значение
1.Ставка программиста	руб/час	Сп	50
2.Норма отчислений в фонды с з/п *	%	Но	27
3.Время разработки программного продукта	час	Тр	75,85
4.Время тестирования	час	Тт	20
5.Опытная экплуатация разработки	час	То	15
6.Доработка программы	час	Тд	10
7.Разработка документации	час	Тдок	6

Таблица 5.2 Данные для расчета норм отчислений в фонды(Но)

Норма отчислений в фонды з/п	Значение
в пенсионный фонд	20%
в фонд соцстраха	2,90%
в фонд мед. страха	3,10%
на страхование от несчастных случаев на производстве	1%
Итого	27%

Кп = Сп*(Тр+Тт+То+Тд+Тдок)*((Но+100%)/100%)

Кп = 50*(75,85+20+15+10+6)*1,27 = 8054,98 руб.

 

12.2 Расчет трудовых и стоимостных затрат

Расчет трудовых затрат в часах (Т) и стоимостных затрат в рублях (С) на на настройку ПЭВМ.

Исходные данные для расчета представлены в таблице 5.3

Таблица 5.3

Наименование показателя	Ед. изм.	Обозначение	Значение
			было	стало
1.Затраты времени на работу администратора на настройку 1 ПЭВМ	Час	О0,О1	1,3	0,5
2.Ставка администратора	руб/час	Сто	45	45
3.Норма отчислений в фонды с з/п	%	Но	27	27
4.Годовой фонд рабочего времени при 40 часовой рабочей неделе	Час	Ф	1987	1987

Трудовые затраты в часах на настройку ПЭВМ по базовому варианту (То), при условии траты на обработку 20% рабочего времени:

То = Ф*30% = 1987*0,2=397,4 час.

Рассчитаем количество ПЭВМ за год по базовому варианту:

К = То/О0 = 397,4/1,3= 306.

Трудовые затраты в часах на настройку ПЭВМ по предлагаемому проекту (Т1):

Т1 = К*О1 = 306*0,5 = 153 час.

Стоимостные затраты за год в рублях на настройку ПЭВМ по базовому варианту (С0):

Со = (Сто*T0)*((Но+100%)/100%) = (45*397.4)*1,27 = 22711,41 руб.

Стоимостные затраты за год в рублях на настройку ПЭВМ по проектному варианту(С1), приведенные к единому размеру с помощью нормативного коэффициента окупаемости(Ен=0,33)

С1 = (Сто*T1)*((Но+100%)/100%)+Кп*Ен = (45*153)*1,27+8054,98*0,33 = 8743,95+2658 = 11402,1 руб.

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

 

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

К трудовым показателям относятся:

) абсолютное снижение трудовых затрат (DТ) в часах за год:

DТ = Т0 - Т1

где Т0 - трудовые затраты в часах за год на настройку по базовому варианту;

Т1 - трудовые затраты в часах за год на настройку по предлагаемому варианту;

DТ = Т0 - Т1, = 397,4 - 153 = 244,4

) коэффициент относительного снижения трудовых затрат (КТ):

КТ =DТ / T0 * 100% ;

КТ =244,4 /397,4 * 100% =61,5%

) индекс снижения трудовых затрат или повышение производительности труда (YT):

YT = T0 / T1.

YT = 397,4/ 153 = 2,6

Таблица 5.4 Показатели эффективности от внедрения проекта

	Затраты		Абсолютное изменение	Коэффициент изменения	Индекс изменения
	базовый вариант	проектный вариант	Затрат	затрат	затрат
Трудоем-кость	T0	T1	DТ=Т0 -Т1	КТ=DТ /T0 *100 %	YT=T0/T1
	(час)	(час)	(час)
	397,4	153	244,4	61,5%	2,6

Из таблицы 4 видно, что в результате внедрения рассматриваемого проекта было достигнуто значительное снижение как трудоемкости процесса настройки ПЭВМ, так и его стоимость. В частности, YT составляет 2,6, то есть достигается увеличение производительности труда в 2,6 раз.

 

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

К стоимостным показателям относятся: абсолютное снижение стоимостных затрат (DC) в рублях за год, коэффициент относительного снижения стоимостных затрат (КC) индекс снижения стоимостных затрат (YC). Данные показатели рассчитываются по следующим формулам:

) абсолютное снижение стоимостных затрат (DС) в рублях за год:

DС = С0 - С1

где С0 - стоимостные затраты в рублях за год на настройку ПЭВМ по базовому варианту;

С1 - приведенные стоимостные затраты в рублях за год на настройку ПЭВМ по предлагаемому варианту;

DС = С0 - С1 = 22711,41 - 11402,1= 11309,37руб

) коэффициент относительного снижения стоимостных затрат (КС):

КС =DС / С0 * 100% ;

КС = 11309,37 / 22711,41*100% = 49,8%

) индекс снижения стоимостных затрат (YС):

YС = С0 /(С1- Кп*Ен) .

YС = 22711,41 /(11402,1-8054,98*0,33) = 22711,41/(11402,1 - 2658) = 22711,41/8717,1 =2,6

На рисунках 5.1 и 5.2 представлены показатели эффективности от внедрения проекта, представлены в виде диаграмм.

Рис.5.1 Снижение трудоемкости

Рисунок 5.2 Снижение затрат

Рассчитаем годовую экономию от внедрения проекта.

DC - годовая экономия (абсолютное снижение стоимостных затрат в рублях за год):

DC = С0 - С

Где С - стоимостные затраты в рублях за год на настройку ПЭВМ по предлагаемому варианту после внедрения проекта:

С = (Сто*Т1)*((Но+100%)/100%)

С = (45*153)*1,27 = 8743,95

DC = 22711,41 -8743,95= 13967,46

Помимо рассмотренных показателей целесообразно также рассчитать срок окупаемости затрат на внедрение проекта настройки новых ПЭВМ (Ток), рассчитываемые в годах, долях года или в месяцах года:

Ток = КП /DC

Где Кп - затраты на создание проекта;

DC - годовая экономия.

Таким образом, срок окупаемости:

Ток = 8054,98/13967,46=0,58≈6,96мес.

Становится понятна выгода от использования внедряемой системы. Администратор, при меньших затратах, будет выполнять больший объем работ.

Список литературы

1. www.toolsru.com/docs/19-20/86-90.pdf

. http://maccentre.ru/lib/2197/

. http://www.interface.ru/borland/bcb.htm

. http://ru.wikipedia.org

5. <http://oracle.axoft.ru/fordev/advantagesOracle.php>

. Когаловский М.Р. Энциклопедия технологий баз данных. - М: Финансы

и статистика, 2002. - 800 с.: ил.

. Братищенко В.В. Проектирование информационных систем. - Иркутск:

Изд-во БГУЭП, 2004. - 84 с.

. Вендров А.М. Проектирование программного обеспечения экономических

информационных систем. - М.: Финансы и статистика, 2000.

. Орлик С., "Модели жизненного цикла <http://swebok.sorlik.ru/software_lifecycle_models.html>

. <http://www.insapov.ru/idef0-standard-description.html>

11. Вавинов, С. В. Параметризованный жадный алгоритм построения статических расписаний / С. В. Вавинов, В. А. Костенко Методы и средства обработки информации: тр. всерос. науч. конф., Москва, 1-3 октября 2003 г. М Издательский отдел факультета ВМиК МГУ, 2003. - С. 323-328.

. Крюков, В. А. Разработка параллельных программ для вычислительных кластеров и сетей / В. А. Крюков // Информационные технологии и вычислительные системы. - 2003. - № 1-2. - С. 42-61.

ЗАКЛЮЧЕНИЕ

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

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

В экономическом разделе проекта приведен расчет экономической эффективности от использования разработанного программного обеспечения, годовая экономия составила 13968 руб., срок окупаемости 7 месяцев.