Управление инженерными данными на этапе концептуального проектирования ракеты-носителя

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

1.5 Постановка задачи магистерской диссертации

1) Провести аналитическое исследование предметной области - проектного отдела с точки зрения информационной поддержки.

2) Выявить узкие места.

3) Создать модели процесса проектирования РН как есть.

4) Сравнить различные методологии моделирования.

5) Создать УСП одного из блоков РН.

6) Описать систему управления инженерными данными на этапе концептуального проектирования

7) Представить экономические аспекты внедрения АСУП.

2 АНАЛИЗ ПРОЦЕССА НИСХОДЯЩЕГО ПРОЕКТИРОВАНИЯ

2.1 Основы концептуального проектирования

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

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



Рисунок 2.1 - Часть структуры предприятия «ЦСКБ - Прогресс»

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

Теперь рассмотрим схему организации работ по разработке проектно-расчётной документации РН на предприятии «ЦСКБ - Прогресс» (рисунок 2.2).

Рисунок 2.2 - Схема организации работ по разработке проектно-расчётной документации РН на предприятии «ЦСКБ - Прогресс»

Служба ведущих конструкторов:

ѕ после получения ТЗ оформляет приказ на проведение работ подразделениями в соответствии с их тематическим направлением по РН;

ѕ выдаёт в экономическую службу данные по объёмам и срокам выполнения работ.

Проектный отдел по РН:

ѕ обеспечивает рассмотрение и согласование ТЗ, направленное на проведение работ по применению РН;

ѕ обеспечивает выдачу в службу ведущих конструкторов объём и сроки выполнения собственных работ и смежных предприятий;

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

ѕ оформляет отчёты по выполнению этапов работ по договору;

ѕ разрабатывает исходные данные, необходимые для проведения работ тематическими подразделениями.

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

ѕ обеспечивают выдачу в службу ведущих конструкторов и экономическую службу;

ѕ оформляет отчёты по выполнению этапов работ;

ѕ разрабатывают и выдают в проектный отдел материалы для оформления сводных документов (ТП, ПЗ, Заключения).

Экономическая служба обеспечивает заключение договора на проведение работ по применению РН.

Плановая служба обеспечивает планирование работ подразделениям по данной тематике.[17]

Теперь попытаемся выделить проектный отдел из общей структуры предприятия. Для этого рассмотрим документооборот на уровне отдела. Построим блок - схему структуры проектного отдела. Обратимся к рисунку 2.3.



Рисунок 2.3 - блок - схема структуры проектного отдела

Один из заместителей начальника курирует технические вопросы по проектным параметрам РН и СЗБ. Другой - вопросы разработки конструкции РН и СЗБ и их конструктивной увязки с составными частями КРН, с КГЧ и с полезным грузом. Начальники секторов курируют работу начальников групп и ведущих инженеров конструкторов. Начальники групп разрабатывают документацию (ТЗ,ТЧ, отчёты, заключения, анализ нештатных ситуаций, критерии аварийных ситуаций) на комплекс РН, ракетные блоки в соответствии с требованиями заказчика по ТТЗ, проводят контроль основных параметров конструкции РН (точность, стабильность, объёмы баков и магистралей и т.д.) и ракетных блоков на всех стадиях ОКР. Ведущий инженер по направлению ТТЗ на КРН и условиям эксплуатации РН занимается технической увязкой различных полезных грузов и КГЧ с КРН и, при необходимости, разрабатывает ТЗ на СЗБ для различных РКК, пояснительные записки, ТЧ на СЗБ и РКН, поводит контроль основных параметров конструкции СЗБ на всех стадиях ОКР (точность, стабильность, объёмы и др.).Начальник группы по разработке конструкций СЗБ и увязке КГЧ с КРН, как видно по названию его должности, занимается разработкой конструкции СЗБ и увязке КГЧ с КРН (точнее курирует работу проектантов работающих в данном направлении).Ведущие инженеры занимаются обеспечением выполнения требований контракта и обеспечением технической увязки составных частей РН.

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

В обязанности проектантов входит:

1) Принятие проектных решений средней сложности по отдельному разделу части проекта;

2) Подготовка соответствующего раздела части пояснительной записки;

3) Участие в подготовке главным специалистом технического задания смежным отделам;

4) Участие в сборе исходных данных для проектирования;

5) Осуществление авторского надзора за производством проектируемых объектов по вопросам входящих в его компетенцию;

6)Текущее информирование главного специалиста производственного отдела о состоянии процесса разработки проектной документации.

Таким образом, путь указания от начальника к проектанту и путь отчётов о проделанной работе можно представить следующим образом (рисунок 2.4).

Рисунок 2.4 - схема пути указания от начальника к проектанту и пути отчётов о проделанной работе

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

Теперь приступим к рассмотрению работы потока конкретных документов связанных с проектным отделом. Сначала выделим основные этапы работы и ключевые документы. Для этого обратимся к рисунку 2.5.



Рисунок 2.5 - Основные этапы работы проектного отдела и сопутствующие ключевые документы

Ознакомимся с каждым этапом подробнее.

1.Техническое предложение (ТП) - совокупность конструкторских документов, которые должны содержать уточненные технические и технико-экономические обоснования целесообразности разработки документации изделия на основании:

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

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

Техническое предложение разрабатывается с целью выявления дополнительных или уточненных требований к изделию (технических характеристик, показателей качества и др.), которые не могли быть указаны в техническом задании, и это целесообразно сделать на основе предварительной проектной проработки и анализа различных вариантов изделия. В техническое предложение включают документы проектантов, предусмотренные техническим заданием. При выполнении документов в электронной форме электронная структура изделия и электронная модель изделия (сборочной единицы, комплекса) выполняются со степенью детализации, соответствующей стадии технического предложения. Конструкторские документы, разрабатываемые для изготовления материальных макетов, в комплект документов технического предложения не включают. Допускается включать в комплект документов технического предложения электронные макеты вариантов изделия и (или) его составных частей по ГОСТ 2.052 - 2006. Форма представления документов технического предложения (бумажная или электронная), если она не указана в техническом задании, определяется разработчиком по согласованию с заказчиком. Виды документов устанавливаются согласно ГОСТ 2.102 - 68. Допускается включать в комплект документов технического предложения документы в различных формах представления. ТП включает чертёж общего вида, ведомость и пояснительную записку. На стадии технического предложения чертеж общего вида или эквивалентная ему электронная модель сборочной единицы в общем случае должны содержать:

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

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

в) размеры и другие наносимые на изображение данные (при необходимости);

г) схему, если она требуется, но оформлять ее отдельным документом нецелесообразно;

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

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

Допускается также:

ѕ изображать контурными очертаниями любые составные части изделия;

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

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

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

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

а) в разделе «Введение» указывают наименование, номер и дату утверждения технического задания;

б) в разделе «Назначение и область применения разрабатываемого изделия» приводят соответствующие сведения из технического задания, а также сведения, конкретизирующие и дополняющие техническое задание, в частности:

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

ѕ общую характеристику объекта, для применения в котором предназначено данное изделие (при необходимости);

в) в разделе «Техническая характеристика» приводят:

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

г) в разделе «Описание и обоснование выбранной конструкции» приводят:

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

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

ѕ фотографии материальных макетов (при необходимости);

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

ѕ данные проверки вариантов на патентную чистоту и конкурентоспособность;

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

ѕ сведения о соответствии вариантов требованиям техники безопасности и производственной санитарии;

ѕ сведения о безопасности изделия и его воздействии на окружающую среду;

ѕ сведения по утилизации изделия;

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

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

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

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

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

В приложении к пояснительной записке приводят:

ѕ копию технического задания;

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

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

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

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

2.Тактико-техническое задание (ТТЗ) - исходный технический документ Заказчика на выполнение необходимого комплекса научно-исследовательских и экспериментальных работ в подтверждение выбранной концепции и облика нового (модернизированного) образца и в обеспечение реализации его основных ТТХ в установленные сроки. На основании ТТЗ Головной разработчик при необходимости разрабатывает и выдает своим соразработчикам технические задания (ТЗ) на выполнение т.н. "частных НИР" в обеспечение разработок наиболее сложных составных частей образца.

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

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

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

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

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

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

В общем случае при разработке эскизного проекта проводят следующие работы:

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

б) предварительное решение вопросов упаковки и транспортирования изделия;

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

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

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

е) оценку изделия по показателям стандартизации и унификации;

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

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

и) проверку соответствия вариантов требованиям техники безопасности и производственной санитарии;

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

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

ѕ назначения;

ѕ надежности;

ѕ технологичности;

ѕ стандартизации и унификации;

ѕ экономическим;

ѕ эстетическим;

ѕ эргономическим.

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

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

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

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

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

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

В результатом прохождения этих двух этапов является УСП (управляющая структура проектанта). УСП представляет собой блок-схему, содержащую:

1) Уровни Управляющей структуры.

2) Участников проекта, в виде отделов.

3) Состав каждой Управляющей сборки.

4) Обозначение, наименование и название файла модели для каждого элемента.

5) Фиксацию, на каком уровне, в каком виде и каким отделом формируются расчетные модели.

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

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

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

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

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

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

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

ѕ регламентировать отношения. Один из самых важных моментов! Заказчик и исполнитель регламентируют объёмы, сроки, денежные суммы, порядок приёмки, форматы исходных и выходных данных и ещё множество условий, которые необходимо прописать во избежание конфликтных ситуаций.

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

Существует мнением, что техническое задание не нужно, что оно будет только мешать и тормозить процесс разработки, сковывать его. На мой взгляд, это крайне неверная позиция. Это позиция людей некомпетентных, непрофессиональных. Почему таким людям (это, как правило, разработчики) выгодно отсутствие ТЗ? А вот почему:

1) Это скрывает отсутствие опыта, слабое представление сути дела, за которое берётся разработчик;

2) Это даёт возможность затянуть разработку и увеличить бюджет;

3) Это позволит недобросовестному исполнителю безнаказанно урезать объёмы работ, ухудшать характеристики;

4) Это позволит исполнителю «левачить» - заниматься другой разработкой в то время, пока заказчик ему платит. Разработчик может выполнять часть работ, якобы нужных для проекта, а потом сдавать их на сторону.

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

ѕ Задача такая сложная и такая «творческая», что её невозможно загнать в рамки ТЗ!

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

ѕ Написание ТЗ займёт много времени и ресурсов. Уж лучше взяться потихонечку за работу, а там - определимся!

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

ѕ ТЗ не нужно, поскольку задача слишком очевидна и проста!

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

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

Техническое задание должно удовлетворять следующим требованиям.

ѕ Полнота - как можно более полное описание системы, целей и задач;

ѕ Логичность - описания не должны быть противоречивыми

ѕ Правильность - отсутствие ошибок, которые могут вести к двусмысленности или некорректности;

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

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

1) Технические требования и стандарты;

2) Структура;

3) Функциональное содержание отдельных структурных элементов;

4) Состав работ и сроки выполнения;

5) Стоимость работ.

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

2.2 Моделирование процесса концептуального проектирования РН «как есть»; документооборот внутри проектного отдела

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

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

Процесс моделирования подразделяется на 4 уровня:

1) Концептуальный уровень, когда определяются границы системы (элемента), т.е. указываются векторы входных и выходных координат системы (элемента).

2) Топологический уровень, когда определены связи входных, выходных и внутренних переменных системы.

3) Структурный уровень, когда определена структура операторов, описывающих взаимосвязь входных, выходных и внутренних переменных.

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

Как видно из темы раздела мы будем рассматривать 1 уровень моделирования. На концептуальном уровне могут решаться задачи декомпозиции (разбиения) на подсистемы и агрегации (объединения) подсистем в систему. Эти процедуры являются неотъемлемыми элементами анализа и синтеза сложных систем, в том числе, на основе системного подхода. Основа методов декомпозиции и агрегации - мнение экспертов, специалистов предметной области.

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

Теперь определимся, что же будет смоделировано. Под процессом будем понимать бизнес-процесс (БП). Разберёмся, что же такое БП и что понимается под его моделью.

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

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

Вход в БП - ресурс, необходимый для выполнения БП.

Выход БП - это результат (продукт, услуга) выполнения БП.

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

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

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

ѕ только повышение результативности и эффективности процессов может обеспечить организации конкурентоспособное будущее;

ѕ реальная деятельность представляет собой процессы;

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

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

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

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

Количественная оценка БП это его эффективность.

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

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

Возникает вопрос по какой причине принимается решение по моделированию бизнес-процессов компании. Как правило основной причиной является снижение конкурентоспособности предприятия. Моделирование БП направлено на установление причины снижения эффективности политики проводимой организацией(снижение прибыли при неизменном или увеличивающемся количестве затрачиваемых ресурсов). То есть моделирование направлено на достижение «технологической прозрачности» деятельности компании и изучение перспективы развития организации. Результатом моделирования БП являются:

ѕ сведения о функционировании подразделений и сотрудников;

ѕ сведения о правильности распределения прав и обязанностей руководителей;

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

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

2.2.1 Модель процесса концептуального проектирования «как есть»

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

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

ѕ что поступает в подразделение «на входе»;

ѕ какие функции (и в какой последовательности) выполняются каждым подразделением;

ѕ кто является ответственным за выполнение каждой из функций;

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

ѕ что является результатом работы подразделения «на выходе».

Для лучшего понимания работы проектного отдела для начала рассмотрим упрощённую схему работы проектного отдела (рисунок 2.6).

Рисунок 2.6-Схема работы проектного отдела.

Рассмотрим по подробнее работу проектного отдела. Для модели "как есть", в качестве примера, рассмотрим работу проектного отдела в ракетно-космическом центре "ЦСКБ - Прогресс". Проектирование осуществляется следующим образом: проектант, работая на сервере PDM-системы Windchill, проектирует мастер - геометрию. Так как все данные хранятся на сервере в одном экземпляре, исключена возможность их неактуальности.

Затем делает с МГП ассоциативно связанные Теоретический Чертеж в Creo, что исключает ошибки из-за отсутствия импорта геометрии между разными САПР. Далее проектант согласовывает и утверждает модели с чертежами в среде Windchill и на бумажных носителях. Проектант с Листами Запуска на модели и чертежи должен согласовать документацию с вышестоящим начальством начиная с начальника группы, далее процесс проходит через начальника отдела, технологов и т.д. вплоть до утверждения чертежей заказчиком.

Согласование в бумажном виде происходит часто не оперативно, и документы задерживаются на одном из этапов согласования, останавливая тем самым производство. Сразу после утверждающей подписи на соответствующих «бумагах», документам и моделям на сервере в Windchill присваивается статус "выпущено". Далее с выпущенными объектами могут начинать работать другие подструктуры предприятия.

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

Рассмотрим деятельность проектного отдела ещё более подробно (уровень конкретных документов). Для этого используем методологию ARIS, основные моменты которой описаны выше, а именно нотацию aeEPC

2.2.2 Нотация aeEPC

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

Для получения более полных знаний о методологии и других нотациях воспользуйтесь пособием «Интегративное проектирование единого информационного пространства предприятия» написанным А.В. Иващенко, С.С. Кожевниковым, М.Е Кременецкой. [14]

Графические элементы для описания процесса с использованием нотации aeEPC

Рисунок 2.7 - Графические элементы нотации aeEP



Рисунок 2.7 продолжение - Графические элементы нотации aeEPC

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

Из диаграммы видно, что работа проектного отдела начинается на основании приказа по предприятию о разработке технического предложения (ТП)по заказу сразу после заключения контракта между директором и заказчиком. Этим приказом определяется начальник проектной группы по конкретному изделию. Затем проектанты отдела выпускают техническое решение по вопросу создания ТП. В нём прописывается перечень необходимых работ, исполнители сроки исполнения заданий. После согласования этого решения с высшим руководством проектного отдела, высшим руководством предприятия, высшим руководством отдела-разработчика и отдела исполнителя техническое решение переносится на кальку и выпускается листок запуска. Листок запуска прикрепляется к запущенному проекту, содержит отметки о согласованиях, номера и названия документов, номера чертежей, наименования моделей и рассылается по отделам исполнителям. После этого архиватор заносит сведения о решении в «ЛОЦМАН», а проектант заносит решение в Windchill, калька сдаётся в архив. Затем проектанты составляют (этим всегда занимается один и тот же человек, ответственный за составление ФИД, листов запуска и т.п.) «Форму исходных данных» (ФИД). ФИД - это документ, сопровождающий создаваемое изделие, включающий все пункты решения о выполнении тех или иных работ, сроки исполнения работ, исполнителей и визы проверяющих. По выполнении работы исполнителем оформляется карточка контроля, и оформленная карточка отправляется на подпись проверяющему. После окончания всех работ вся отчётная документация стекается к начальнику отдела, и проектанты проектного отдела подготавливают отчёт о выполненных технического решения.

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

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

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

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

В Windchill документу присваивается статус «на проверке». Если ошибок в построениях нет и отклонений от ТТЗ не обнаружено, то контрольной карточке ставится подпись проверяющего, а в Windchill документу присваивается статус «проверено». Или же, если найдены недочёты контрольная карточка не подписывается, и проверяющий отправляет УСП обратно разработчику. В Windchill документу присваивается статус «доработать». После доработки МГП снова отправляется к ведущему инженеру-конструктору. Он её проверяет, подписывает, если его всё устроило или опять отправляет на доработку. Количество итераций не ограничено. После проверки УСГП отправляется на согласование к главному конструктору и начальнику проектного отдела. Если нареканий нет, то УСП согласуется (отметка в ЛЗ и в ТР). Если кого то из участников согласования что - то не устраивает УСП отправляется на доработку (отметка в листе запуска) затем на проверку и снова на согласование.

Приступим к описанию процесса создания ТЧ в Creo Elements. ТЧ создаётся, затем ТЧ проверяется ведущим инженером-конструктором. Если нареканий нет (ТЧ сделан по нормативной документации и совпадает с МГП), то подписывается контрольная карточка и ТЧ отправляется на согласование в конструкторский отдел. Сопровождающая документация всё та же: ЛЗ, ТР, служебная записка на случай «не согласования». Если ТЧ проверку не прошёл, то он отправляется на доработку к разработчику и сопровождается служебной запиской. Для запуска ТЧ и УСП создаются два отдельных листа запуска. Это делается по следующим причинам:

1) Заказчик расписывается только в листе запуска на ТЧ, так как проверяет только ТЧ;

2) В УСП содержится много информации, которая не используется при разработке ТЧ. Следовательно, при необходимости доработки УСП доработка ТЧ не всегда нужна. Возможна обратная ситуация: при доработке ТЧ УСП изменений не требует.

После согласования ТЧ и УСП проходят проверку входного контроля. На этом этапе проверяются на соответствие нормативно - технологической документации чертёж, модель, все названия, номера и обозначения(отметка в листе запуска и ТР). Если документация прошла входной контроль то она вместе со всей сопровождающей документацией отправляется в архив и «ЛОЦМАН», где хранится в дальнейшем. В системе Windchill ей присваивается статус «выпущено».

Достоинствами этого процесса являются:

ѕ экономия времени проектанта в связи с полной интегрируемостью систем Creo Elements (Pro/ENGINEER) и Windchill;

ѕ актуальность данных;

ѕ простота внесения изменений в КД;

Явным недостатком моделируемого процесса является долгий процесс согласования как первоначальной документации, так и вносимых в неё изменений. Это значительно увеличивает время выпуска проектной документации и затраты на выпуск проекта изделия.

Согласование только в среде Windchill невозможно из - за отсутствия электронно - цифровой подписи на предприятии.

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

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

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

ѕ Защиту от изменений (подделки) документа: гарантия выявления подделки при контроле целостности делает подделывание нецелесообразным в большинстве случаев.

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

- Доказательное подтверждение авторства документа: Так как создать корректную подпись можно, лишь зная закрытый ключ, а он должен быть известен только владельцу, то владелец пары ключей может доказать своё авторство подписи под документом. В зависимости от деталей определения документа могут быть подписаны такие поля, как «автор», «внесённые изменения», «метка времени»

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

3. РЕАЛИЗАЦИЯ УПРАВЛЕНИЯ ИНЖЕНЕРНЫМИ ДАННЫМИ

3.1 Программные продукты, используемые при реализации управления инженерными данными

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

ѕ Creo Elements, как среда разработки модели;

ѕ Windchill PDMLink, как система управления данными.

Ознакомимся с каждой из систем.

3.1.1 Creo Elements (Pro/ENGINEER)

Creo Elements (Creo Elements (Pro/ENGINEER Wildfire) - мощная система твердотельного моделирования, используемая для создания 3D моделей деталей и сборок. В процессе проектирования деталей могут быть задействованы и другие модули Creo Elements (Pro/ENGINEER), например чертежный модуль.

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

Creo Elements (Creo Elements (Pro/ENGINEER Wildfire) позволяет быстро создавать, редактировать и ориентировать модель с помощью Windows-стилизованного интерфейса. Важной составляющей интерфейса являются Навигатор папок и Web браузер. С помощью этих инструментов можно быстро находить, предварительно просматривать и загружать модели. Также, непосредственно в среде Creo Elements (Creo Elements (Pro/ENGINEER) Wildfire), получается доступ к Web ресурсам и возможности совместной удаленной работы с другими инженерами. [19]

Creo Elements (Pro/ENGINEER) включает десять функциональных режимов. Режим является средой для выполнения конкретных задач, например режим Drawing (Чертеж) или Part (Деталь). Режимы обладают ассоциативностью; изменения модели, сделанные в одном режиме работы, автоматически отражаются на модели, когда она рассматривается или обновляется в другом режиме. Например, изменения детали отражаются на ее чертеже (связь Деталь-Чертеж).

Параметрическое конструирование.

Управление геометрией в Creo Elements (Pro/ENGINEER) осуществляется через линейные, угловые и диаметральные размеры конструкции. Пользователь может вводить соотношения для автоматического вычисления одних параметров через другие. Изменение пользователем какого-либо размера приводит к пересчету всей модели в соответствии с введенными связями.

Моделирование на основе конструктивных элементов.

Пользователь создает модели в Creo Elements (Pro/ENGINEER) из конструктивных элементов. Такие блоки включают информацию об окружении и изменяются заданным образом. Каждый конструктивный элемент запрашивает у пользователя характерные только для него данные. Например, отверстие имеет диаметр, глубину и место расположения, в то время как скругление имеет радиус и перечень скругляемых кромок.

Ассоциативность.

Creo Elements (Pro/ENGINEER) является полностью ассоциативной системой. Это означает, что изменение, сделанное в модели, всякий раз проходит через конструкцию с выполнением автоматической корректировки всех связанных разработок, включая сборки, рисунки и сведения о процессе производства. Ассоциативность делает возможным процесс параллельного проектирования за счет надежной поддержки модификаций на любой стадии цикла разработки изделия. Это позволяет инженерным подразделениям, выполняющим обычно работы в конце цикла, вносить свой вклад уже на ранней стадии.