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

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

Министерство образования и науки Российской Федерации

Государственное образовательное учреждение

высшего профессионального образования

САМАРСКИЙ ГОСУДАРСТВЕННЫЙ

АЭРОКОСМИЧЕСКИЙ УНИВЕРСИТЕТ

ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА

МАГИСТРА

магистерская программа “Проектирование и конструирование ракетно-транспортных систем”

Тема: УПРАВЛЕНИЕ ИНЖЕНЕРНЫМИ ДАННЫМИ НА ЭТАПЕ КОНЦЕПТУАЛЬНОГО ПРОЕКТИРОВАНИЯ РАКЕТЫ-НОСИТЕЛЯ

Научный руководитель

доцент, к.т.н. Горячев О.А.

Магистрант

Паршин С.С.

Самара 2014

РЕФЕРАТ

Пояснительная записка:126 стр., 82 рис., 25 источников, 3 приложения.

ЕДИНОЕ ИНФОРМАЦИОННОЕ ПРОСТРАНСТВО, ЖЦИ, ИПИ-ТЕХНОЛОГИИ, PDM СИСТЕМА, УПРАВЛЯЮЩАЯ СТРУКТУРА ИЗДЕЛИЯ, УПРАВЛЯЮЩАЯ СБОРКА ПРОЕКТАНТА, ПРОЦЕСС СОГЛАСОВАНИЯ, CREO ELEMENTS, ЭЛЕКТРОННЫЕ МОДЕЛИ, ТЕХНОЛОГИЯ РАЗРАБОТКИ, САПР, ТРЕБОВАНИЯ К МОДЕЛИРОВАНИЮ, СБОРКА, ДЕТАЛЬ, НИСХОДЯЩЕЕ ПРОЕКТИРОВАНИЕ, СКВОЗНОЕ ПРОЕКТИРОВАНИЕ, РАКЕТА-НОСИТЕЛЬ, КАРКАСНАЯ МОДЕЛЬ, КОПИЯ ГЕОМЕТРИИ, ПЛАНИРОВАНИЕ РАБОТ, УПРАВЛЯЮЩАЯ СТРУКТУРА, ПРОЕКТАНТ, КОСТРУКТОР, ПРОЕКТИРОВАНИЕ СНИЗУ ВВЕРХ, СТАНДАРТНЫЕ ИЗДЕЛИЯ, ИМЕНОВАНИЕ УЗЛОВ.

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

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

СПИСОК ИСПОЛЬЗУЕМЫХ СОКРАЩЕНИЙ

АСУП - Автоматизированная Система Управления Предприятием

БП - Бизнес-Процесс

ВГ - Внешняя Геометрия

ГПО - Головной Проектный Отдел

ГР - Модель Границ

ЕИП - Единое Информационное Пространство

КА - Космический Аппарат

КБ - Конструкторское Бюро

КГЧ - Космическая Головная Часть

КД - Конструкторская Документация

КРН - Конструкция Ракеты-Носителя

ЛЗ - Лист Запуска

МГП - Мастер - Геометрия Проектанта

МРП - Модель Распределения Пространства

НИОКР - Научно - Исследовательская и Опытно-Конструкторская Работа

НИР - Научно - Исследовательская Работа

ОКР - Опытно - Конструкторская Работа

ПЗ - Полётное Задание

ПН - Полезная Нагрузка

РКК - Ракетно - Космический Комплекс

РКН - Ракета Космического Назначения

РН - Ракета-Носитель

САПР - Система Автоматизированного Управления Предприятием

СЗБ - Сборочно-Защитный Блок

ТЗ - Техническое Задание

ТП - Техническое Предложение

ТР - Техническое Решение

ТТЗ - Тактико - Техническое Задание

ТЧ - Теоретический Чертёж

УМ - Управляющая Модель

УСП - Управляющая Сборка Проектанта

ФИД - Форма Исходных Данных

ЭМ - Эскизная Модель

ЭЦП - Электронно-Цифровая Подпись

aVAD - adaptive Value Added Chain Diagram -адаптивная диаграмма цепочки процессов, добавляющих стоимость

aeEPC - adaptive extended Event Driven Process Chains - адаптивная расширенная цепочка процесса, управляемого событиями

CAD - Computer Aided Design - компьютерное проектирование

OCL - язык описания ограничений - формальной проверки правильности

PDM - Product Data Management - управление данными о продукте

UML-Unified Modeling Language- язык визуального моделирования, основанный на объектно-ориентированном подходе

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

. АНАЛИЗ МЕТОДОВ ПРОЕКТИРОВАНИЯ И ПРОЦЕССА КОНЦЕПТУАЛЬНОГО ПРОЕКТИРОВАНИЯ РАКЕТЫ - НОСИТЕЛЯ

.1Нисходящее проектирование

.1.1 Параллельное проектирование

.1.2 Последовательное проектирование (нисходящее и восходящее)

.1.3 Спиральная модель

.1.4 Сравнительный анализ методов проектирования

.2Методологии моделирования БП

.2.1Методология UML

.2.2 Методология ARIS

.3 Моделирование процесса нисходящего проектирования изделия (диаграммы ARIS и UML)

.3.1 Моделирование процесса нисходящего проектирования изделия; диаграммы ARIS

.3.2 Моделирование процесса нисходящего проектирования изделия; диаграмма UML(диаграмма состояний)

.4 Ракета - носитель как объект проектирования (назначение, особенности проектирования, возникающие сложности)

.5 Постановка задачи дипломной работы

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

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

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

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

.2.2 Нотация aeEPC

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

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

.1.1 Creo Elements (Pro/ENGINEER)

.1.2 Windchill PDMLink

.2 Разработка управляющей сборки проектанта

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

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

.2.3 Создание управляющей сборки проектанта

.2.4 Создание теоретического чертежа

.3Процесс согласования проектной документации в Windchil

.3.1 Описание процесса согласования ПД

.3.2 Описание ролей

.3.3 Авторизация в системе Windchill

.3.4 Запуск процесса «Согласование ПД»

.3.5 Проверка документации

.3.6 Согласование документации

.3.7 Утверждение документации

.3.8 Отправка документации во входной контроль и в архив

. ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ ЦЕЛЕСООБРАЗНОСТИ ВНЕДРЕНИЯ АВТОМАТИЗИРОВАННОГО УПРАВЛЕНИЯ

ВЫВОДЫ О ПРОДЕЛАННОЙ РАБОТЕ

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

ПРИЛОЖЕНИЯ

ВВЕДЕНИЕ

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

¾      программные системы геометрического моделирования и автоматизации конструкторских работ CAD (Computer-Aided Design) или системы автоматизированного проектирования (САПР) - для изготовления сборочных, рабочих и габаритных чертежей, спецификаций, схем и т. д.;

¾      программные системы CAE (Computer-Aided Engineering) -системы инженерного моделирования, анализа и оптимизации, реализующие метод конечных элементов. Наиболее эффективными в мире системами CAE являются программные продукты MSC.Software Corporation - Nastran,Marc, Adams, Dytran и другие;

¾      программные системы CAM (Computer-Aided Manufacturing)- системы технологической подготовки производства с использованием ЭВМ.

¾      системы автоматизированного управления производством (АСУП) - для создания планов производства и отчетов о его ходе;

¾      офисные системы - для подготовки текстовых и табличных документов и т. д.

¾      интегрированные CAD/CAE/CAM системы-системы. [1]

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

Для преодоления этих трудностей потребовались новые концепции и новые идеи. Среди них основной стала идея информационной интеграции стадий жизненного цикла изделия, которая и легла в основу CALS.(Continuous Acquisition and Lifecycle Support - непрерывная информационная поддержка поставок и жизненного цикла) означает совокупность принципов и технологий информационной поддержки жизненного цикла продукции на всех его стадиях. Русскоязычный аналог понятия CALS - Информационная Поддержка жизненного цикла Изделий (ИПИ).

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

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

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

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

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

¾      появляются принципиально новые средства инженерного труда;

¾      полностью изменяется организация и технология инженерных работ;

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

¾      тысячи специалистов должны быть переучены для работы в новых условиях и с новыми средствами труда.

К настоящему времени CALS - технологии образуют самостоятельное направление в области информационных технологий.

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

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

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

¾      резкое сокращение количества ошибок и переделок, что приводит к сокращению сроков реализации проектов и существенному повышению качества продукции;

¾      распространение средств и технологий информационной поддержки на послепродажные стадии жизненного цикла - интегрированная логистическая поддержка изделий.

Как видим, внедрение CALS - технологий приводит к существенной экономии и получению дополнительной прибыли. Поэтому эти технологии и их отдельные компоненты широко применяются в промышленности развитых стран. [4]

Одним из предприятий занимающихся активным внедрением CALS технология является «ЦСКБ - Прогресс». Государственный научно-производственный ракетно-космический центр "ЦСКБ - Прогресс" - ведущее российское предприятие по разработке, производству и эксплуатации РН среднего класса и автоматических космических аппаратов для дистанционного зондирования Земли и научного назначения. На предприятии реализуется большая часть ЖЦИ: от маркетинга до сдачи в эксплуатацию. В настоящее время на предприятии «ЦСКБ - Прогресс» осуществляется программа по внедрению цифровых технологий и совершенствованию методов проектирования и хранения данных об изделиях. В рамках этой программы происходит интеграция САПР КОМПАС (ОАО «Аскон-Самара») и системы Creo Elements(ООО «ПТС»). Система управления жизненным циклом продукции «Лоцман» интегрирована с более совершенной системой - Windchill PDM Link.В будущем планируется полный переход на решения систем Creo и Windchill.

В настоящей работе описывается, каким образом осуществляется информационная поддержка производственной деятельности одного из подразделений предприятия «ЦСКБ - Прогресс» - проектного отдела. К целям проводимой работы относятся:

¾      показать необходимость применения бизнес - моделирования для автоматизации производственного процесса;

¾      показать эффективность использования нисходящего проектирования РН;

¾      показать эффективность применения в совокупности CAD - системы и PDM - системы.

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

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

1. АНАЛИЗ МЕТОДОВ ПРОЕКТИРОВАНИЯ И ПРОЦЕССА КОНЦЕПТУАЛЬНОГО ПРОЕКТИРОВАНИЯ РАКЕТЫ - НОСИТЕЛЯ

.1 Нисходящее проектирование

ракетный космический инженерный автоматизированный

Проектирование - процесс создания проекта, прототипа, прообраза предполагаемого или возможного объекта, состояния.

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

Проект - комплект указанной документации и материалов (определённого свойства), результат проектирования. Проект какого-либо объекта может быть индивидуальным или типовым.[5]

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

Проект должен содержать:

¾      общий замысел;

¾      план создания изделия;

¾      конкретные технические решения по бортовым системам, агрегатам, элементам.

Затраты на выполнение собственно проекта составляют 5-10 % от общих затрат на создание изделия, включающего кроме проектирования:

¾      подготовку производства;

¾      изготовление опытных образцов;

¾      экспериментальную отработку.

Процесс проектирование один из самых важных этапов в ходе создания изделия. Ошибки на этапе проектирования самые "дорогие". Соотношение затрат на исправление ошибок на этапах проектирования, отработки, производства и эксплуатации примерно составляет 1:10:100:1000.

Принципиальные ошибки, как правило, вообще не могут быть исправлены на стадии эксплуатации.

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

. Этап научно - исследовательских работ (поисковые работы, разработка тактико-технических требований).

. Опытно - конструкторские работы (ОКР).

.1. Разработка технического предложения.

.2. Разработка эскизного проекта.

.3. Разработка технического проекта (рабочей документации).

.4. Изготовление опытных образцов и их испытания (этап ОКР).

.4.1. Наземные автономные испытания, включая конструкторско - доводочные испытания.

.4.2. Наземные комплексные испытания.

.4.3. Летные конструкторские испытания.

. Серийное производство.

. Эксплуатация.

Блок - схема алгоритма проектирования РН на начальных этапах разработки ракеты-носителя представлена на рисунке 1.1.

НИР - научно-исследовательские работы

ТЗ - техническое задание

ОКР - опытно- конструкторские работы

Рисунок 1.1 - Алгоритм проектирования

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

Рассмотрим основные виды проектирования

Рисунок 1.2 - Виды проектирования

.1.1 Параллельное проектирование

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

В основе технологии лежит совмещение проектирования изделия, а также планирования его изготовления и сопровождения, координируемые специально предназначенной для этого распределённой информационной средой. Подобная технология позволяет использовать проектные данные с ранней стадии одновременно различными группами специалистов. Например, в трёх главных конструкторских бюро компании BOING 220 групп «проектирование - изготовление», которые координируют параллельные разработки и состоят из специалистов таких разнообразных областей, как проектирование, разработка материалов и прочее. Фактически, при использовании описанной технологии удаётся достичь перекрытия практически всех стадий жизненного цикла изделий.

Жизненный цикл изделия - это период времени, в течение которого формируются:

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

¾      требования к свойствам продукции с их качественными и количественными параметрами;

¾      облик будущей продукции, соответствующий этим требованиям;

¾      технология производства с приемлемыми затратами в конкретных производственных условиях.

Осуществляются:

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

¾      производство продукции;

¾      маркетинг, продажа и обслуживание у покупателя произведенной продукции;

¾      собственно использование продукции в соответствии со служебным назначением.

Завершается жизненный цикл утилизацией использованной и невостребованной продукции.

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

.1.2 Последовательное проектирование (нисходящее и восходящее)

Процесс проектирования изделий с использованием САПР, как правило, может быть реализован в виде двух возможных вариантов:

¾      нисходящего (сверху вниз);

¾      восходящего (снизу вверх) проектирования.

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

Рисунок 1.3 - Принципиальное отличие восходящего и нисходящего вариантов проектирования изделия

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

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

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

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

Методология восходящего проектирования используется для модификации уже разработанных изделий.[9]

1.1.3 Спиральная модель

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

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

Рисунок 1.4 - Спиральная модель

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

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

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

.1.4 Сравнительный анализ методов проектирования

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

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

Но с другой стороны у последовательного проектирования есть ряд существенных недостатков в сравнении с параллельным проектированием. Существенным преимуществом параллельного проектирования является то, что эта технология обеспечивает устранение известных недостатков последовательного проектирования, в частности, когда ошибки проектирования неожиданно обнаруживаются на последних его стадиях. Как показывает отечественный опыт, 50 - 70% имеющихся дефектов готовой продукции машиностроения возникают из-за ошибок в конструкционной работе, 20-30% из-за недостаточной технологичности изделия, 5 - 15% - по вине рабочих.

Устранение первой группы дефектов осуществляется в основном за счёт совмещения проектирования составляющих технологической системы «изделие - технология - оборудование» и раннего учёта возможных при этом ограничений.

.2 Методологии моделирования БП

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

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

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

Рассмотрим некоторые основные методологии.-методология структурного анализа и проектирования (Structured Analysis and Design Technique), основанная на понятиях функционального моделирования. Является методологией, отражающей такие системные характеристики, как управление, обратная связь и исполнители. Возникла в конце 60 - х годов. Базовой книгой по этому вопросу является: Дэвид А. Марка, Клемент МакГоуэн "Методология структурного анализа и проектирования"- методология функционального моделирования. Применяется для описания рабочих процессов (Work Flow). Методология разработана на основе SADT. Для изучения рекомендована книга: "Методология функционального моделирования IDEF0. Руководящий документ. РД IDEF0 - 2000".- методология моделирования потоков данных. Применяется для описания обмена данными между рабочими процессами.- методология моделирования потоков работ. Является более детальной по отношению к IDEF0 и DFD. Позволяет рассмотреть конкретный процесс с учетом последовательности выполняемых операций.X - методология описания данных. Применяется для построения баз данных.- объектно - ориентированная методология. Отражает взаимодействие объектов. Удобна для создания программных продуктов на объектно-ориентированных языках (например С ++).

UML - (Unified Modeling Language) - язык визуального моделирования, основанный на объектно-ориентированном подходе. UML включает в себя диаграммы, которые позволяют описать статическую структуру системы и ее динамическое поведение.- описывает бизнес-процесс в виде потока последовательно выполняемых работ. Ее использует программное средство ARIS Toolset.[12]

Более широко сейчас используется UML и ARIS. Остановимся на этих методологиях более подробно.

.2.1 Методология UML

Данный подход предполагает вначале выделение классов объектов, а далее определение тех действий, в которых участвуют объекты. При этом различают пассивные объекты (материалы, документы, оборудование), над которыми выполняются действия, и активные объекты (организационные единицы, конкретные исполнители, информационные подсистемы), которые осуществляют действия. Такой подход более объективно позволяет выделять операции над объектами, а заодно и решать задачи целесообразности существования самих объектов. Недостаток объектно-ориентированного подхода заключается в меньшей наглядности конкретных процессов для лиц, принимающих решения. Вместе с тем, выявленные операции для наглядности, в дальнейшем могут быть представлены в виде функциональных диаграмм.[13]

.2.2 Методология ARIS

Методология ARIS (Architecture of Integrated Information Systems - архитектуры интегрированных информационных систем) сводится к построению схемы технологического процесса в виде последовательности операций, на входе и выходе которых отражаются объекты различной природы: материальные и информационные объекты, используемые ресурсы, организационные единицы.

Методология ARIS состоит в описании модели процессов в виде четырех интегрированных между собой представлений:

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

¾           информационное представление описывает состояния информационных объектов (данных), и события, приводящие к их изменению;

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

¾           управляющее представление описывает взаимосвязи между указанными представлениями.

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

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

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

¾           на уровне описания реализации спецификация проекта трансформируется в конкретные аппаратные и программные компоненты.

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

.3 Моделирование процесса нисходящего проектирования изделия (диаграммы ARIS и UML)

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

.3.1 Моделирование процесса нисходящего проектирования изделия; диаграммы ARIS

Диаграмма aVAD (adaptive Value Added Chain Diagrams) описывает цепочку процессов добавляющих стоимость. Нотация aVAD позволяет отобразить логическую связь между приоритетными процессами нисходящего проектирования в виде отношения «предыдущий - следующий». [14]

Рисунок1.5 - Нотация aVAD процесса нисходящего проектирования изделия

В данной диаграмме рассмотрены 7 основных процессов (утверждение правил, разработка блок-схем, подготовка библиотек 3D - моделей, создание управляющей структуры из пустых объектов, создание компонентов блок -схемы, создание файлов МГП, создание модели распределения пространств ).

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

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

За тем следует процесс подготовки библиотек 3D - моделей. Перед началом работ необходимо подготовить:

¾      Перечень используемых стандартных и покупных компонентов;

¾      Библиотеку 3D - моделей используемых стандартных и покупных компонентов.

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

Сборки и компоненты создаются на основании разработанной и утвержденной блок-схемы, в которой уже должны быть указаны все атрибуты объектов - "ОБОЗНАЧЕНИЕ", "ПОСТФИКС МОДЕЛИ" (код модели), "НАИМЕНОВАНИЕ". Допустимые типы моделей в управляющей структуре и их сокращения:

Таблица 1.1 - Допустимые типы моделей в управляющей структуре и их сокращения

Для управляющих сборок проектантов и конструкторов вводятся третьи буквы в постфиксы - для проектантов «П» (УСП, МГП и т.п.), для конструкторов «К» (УСК, МГК и т.п.)

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

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

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

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

Между основными процессами отображены потоки материальных ресурсов и информации.

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

Для процесса «разработка блок - схемы изделия» входными «данными» являются утверждённые правила и требования заказчика, выходными «данными» - блок-схема; необходимой инфраструктурой для выполнения процесса - CAD - системы. Подразделением выполняющий процесс является проектный отдел.

Для процесса «подготовка библиотек 3D - моделей» входными «данными» являются списки недостающих объектов; выходными «данными» являются контексты. Контекст предоставляет собой инфраструктуру, из которой выполняются действия пользователя. Подразделениями выполняющими процесс являются проектный отдел и подразделение системных администраторов. Необходимой инфраструктурой для выполнения процесса - PDM - система.

Для процесса «создание управляющей структуры из пустых объектов» входными «данными» являются блок - схема и утверждённые правила; выходными «данными» является управляющая структура из пустых объектов; необходимой инфраструктурой для выполнения процесса - CAD и PDM - системы. Подразделением выполняющими процесс является проектный отдел.

Для процесса «создание компонентов блок-схемы» входными «данными» являются требования заказчика; выходными «данными» являются компоненты блок - схемы; необходимой инфраструктурой для выполнения процесса - CAD и PDM - системы. Подразделением выполняющими процесс является проектный отдел.

Для процесса «создание файлов МГП» входными «данными» являются управляющая структура проектанта, компоненты блок-схемы; выходными «данными» являются созданные файлы МГП; необходимой инфраструктурой для выполнения процесса - CAD и PDM - системы. Подразделением выполняющими процесс является проектный отдел.

Для процесса «создание модели распределения пространства» входными «данными» являются МГП; выходными «данными» является МГП; необходимой инфраструктурой для выполнения процесса - CAD и PDM -системы. Подразделением выполняющими процесс является проектный отдел.

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

.3.2 Моделирование процесса нисходящего проектирования изделия; диаграмма UML(диаграмма состояний)

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

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

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

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

Существует два частных случая состояния. В начальном состоянии объект находится по умолчанию в начальный момент времени. В конечном состоянии объект находится после завершения работы автомата в конечный момент времени. Эти состояния не содержат никаких внутренних действий (псевдосостояний).[14]

Рисунок 1.7 - Обозначения принятые при построении диаграммы состояний

Рисунок 1.8 - Диаграмма состояний процесса нисходящего проектирования изделия

.4 Ракета - носитель как объект проектирования (назначение, особенности проектирования, возникающие сложности)

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

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

Рассмотрим структуру РКК.

Рисунок 1.9 - Структура ракетно-космического комплекса

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

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

¾      разгонный блок и головной обтекатель.

РН состоит из ракетных блоков первой, второй и более ступеней, в которых размещается топливо и двигатели, необходимые для выведения космического аппарата на нужную высоту.[15]

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

. Классификация по грузоподъемности (выведение на круговую орбиту высотой 200 км):

¾      малые (до 5 т);

¾      средние (5…10 т);

¾      тяжелые (10…15 т);

¾      сверхтяжелые (свыше 15 т).

. Классификация по количеству ступеней:

¾      двухступенчатые;

¾      трехступенчатые;

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

. Классификация по схеме соединения ступеней:

¾      с последовательным соединением ступеней (схема "тандем");

¾      с параллельным соединением ступеней (при одновременном начале работы всех ступеней - схема «пакет»);

¾      со смешанным соединением ступеней (ракетные блоки первой и второй ступени соединены параллельно, а ракетный блок третьей ступени соединен последовательно с ракетным блоком второй ступени - так называемый "трехступенчатый пакет";

¾      схема с отделяемыми внешними (боковыми) двигателями.

. Классификация по токсичности топлива:

¾      токсичные (с длительным сроком хранения в заправленном состоянии, например, РН "Протон", конверсионная двухступенчатая баллистическая ракета "Днепр");

¾      нетоксичные (с ограниченным сроком хранения в заправленном состоянии, например, РН "Союз", "Сатурн - V");

¾      с нетоксичными компонентами топлива основных ступеней РН и наличием разгонного блока с токсичными компонентами топлива, например, РН "Союз" с разгонным блоком "Фрегат".

.Классификация по фазовому составу топлива:

¾      жидкие компоненты топлива (РН "Союз", "Сатурн - V" и др.);

¾      твердые компоненты топлива (РН "Старт" на базе баллистических ракет "Пионер" и "Тополь").

¾      ракеты-носители с наличием ракетных блоков и на жидком топливе, и на твердом топливе ("Space Shuttle");

¾      ракеты-носители с наличием ракетных блоков на комбинированных компонентах топлива (твердое горючее и жидкий окислитель, например, проект РН на базе противоспутниковой трехступенчатой ракеты-перехватчика, стартующей с самолета МИГ - 31).

.Классификация по наличию возвращаемых ракетных блоков:

¾      ракетные блоки одноразового применения;

¾      возвращаемые ракетные блоки (спуск на парашюте, на дельтаплане или самолетный спуск ракетных блоков первой ступени, например, ракетный блок «Байкал»).

.Классификация по методу старта:

¾      наземный неподвижный;

¾      наземный подвижный (железнодорожные платформы или тягачи на колесном шасси);

¾      морской старт (с плавучей специальной платформы, например, РН "Зенит");

¾      воздушный старт (с самолетов - носителей, например, проекты "Молния", "Бурлак", проект филиала РКК «Энергия», и др.). [16]

Итак, мы выяснили, что у РН может быть несколько ступеней. Попытаемся понять, от чего зависит их количество. Количество ступеней определяется из соображения минимизации стартовой массы и из условий функционирования РН. Масса уменьшается за счёт используемого топлива. Касаемо функционирования, наличие керосина в ракетном блоке первой ступени и водорода в ракетном блоке второй ступени приводит к перераспределению массы по ступеням ракеты в пользу водородного ракетного блока второй ступени. Однако в этом случае, во - первых, масса ракетного блока второй ступени может оказаться большей, чем масса ракетного блока первой ступени, во-вторых, разделение ступеней будет происходить на относительно низких высотах с достаточно плотной атмосферой и надежность отделения будет снижена. Для того чтобы этого не происходило, первая ступень должна заканчивать работу на высоте не менее 50 км.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

)        Структура;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.2.2 Нотация aeEPC

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.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) из конструктивных элементов. Такие блоки включают информацию об окружении и изменяются заданным образом. Каждый конструктивный элемент запрашивает у пользователя характерные только для него данные. Например, отверстие имеет диаметр, глубину и место расположения, в то время как скругление имеет радиус и перечень скругляемых кромок.

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

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

.1.2 Windchill PDMLink

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

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

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

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

По данным ведущей консалтинговой фирмы CIMdata, Inc. применение PLM - системы дает предприятию следующие преимущества:

¾      сокращение сроков проведения изменений ~ на 40%;

¾      сокращение сроков подготовки опытных образцов на 15-30%;

¾      сокращение времени подготовки производства на 40%;

¾      увеличение производительности в проектировании на 25%;

¾      уменьшение времени разработки изделия ~ на 75%;

¾      уменьшение времени процессов согласования ~ на 80%;

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

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

Для создания систем управления жизненным циклом изделий машиностроительным предприятиям предлагается применять решения Windchill от компании РТС, одного из лидеров среди разработчиков в этой области.

По результатам исследований, проведенных независимой консалтинговой фирмой AMR Research, решения Windchill наиболее полно удовлетворяют требованиям, которые предъявляются к общекорпоративным PLM-системам. Они позволяют объединить в себе и управлять всей информацией о структуре продукта и о его разработке: от концепции - до сдачи в производство, от изготовления отдельных экземпляров - до его вывода из эксплуатации. Windchill отвечает требованиям ISO 9000:2000 по идентификации и прослеживаемости и имеет русскоязычный интерфейс пользователя. Это делает привлекательным использование продукта мирового уровня российскими пользователями и позволяет решать совместные задачи управления, в том числе и с зарубежными партнерами.

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

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

¾      ведение личной записной книжки для хранения любых ссылок;

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

.2 Разработка управляющей сборки проектанта

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

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

Блок схема должна быть выполнена в виде древовидной структуры отдельных блоков и должна содержать:

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

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

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

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

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

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

Рисунок 3.1 - Содержание блока

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

Пользуясь рекомендациями разработаем блок - схему РКН. Обратимся к блок - схеме для РКН, где более подробно рассмотрим РН на уровне проектируемого отсека (Рисунок 3.2).

Рисунок 3.2 - Блок - схема РКН

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

Из блок - схемы видно, что УСП делится на 4 уровня:

.        Уровень РКН.

В мастер-геометрии РКН создаются системы координат (СК) РН и КГЧ. КГЧ может быть представлена в виде Габаритной модели, установленной в УСП уровня РКН, по созданной в МГП СК или для разработки КГЧ создается отдельная УСП, которая устанавливается в УСП уровня РКН, по этой же СК. Создаются специальные модели для аэродинамического расчета наружных обводов РКН (при необходимости).

.        Уровень РН.

Мастер геометрия РН содержит системы координат отдельных блоков.

.        Уровень блоков РН.

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

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

.        Уровень отсеков.

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