WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 |   ...   | 12 | 13 || 15 | 16 |   ...   | 18 |

Задания в графиках могут иметь так называемые триггеры (переключатели) событий, которые срабатывают либо когда задание получено, либо когда задание выполнено. С помощью триггера событий можно инициировать другой график заданий или программу-скрипт, обеспечивая большую гибкость выполняемых действий. Любое задание может находиться или в одном из “стандартных” состояний (work-in-process – не завершено;

registered – зарегистрировано; controlled – контролируется; released – утверждено; frozen – заморожено), или в одном из состояний, заданных пользователем в процессе выполнения действий.

Графики заданий создаются с помощью специального компонента SmarTeam – программы Flow Chart Designer c графическим интерфейсом.

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

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

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

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

Как было отмечено в п. 7, графики производственных заданий (детализированные бизнес-процессы) хранятся в ЕИП ТПП как данные и являются неотъемлемой частью ЕИП. Доступ к этим данным и работа с ними реализуются механизмами Workflow PDM-системы.

С целью обеспечения дополнительного сервиса при планировании сроков выполнения заданий, система SmarTeam обеспечивает интеграцию с системой календарного планирования MS Project. Перечень подлежащих выполнению заданий представлен в MS Project в виде диаграмм Ганта, что позволяет более наглядно видеть имеющийся план и корректировать его.

Поскольку интеграция SmarTeam и MS Project является двунаправленной, то пользователь всегда может выбрать ту форму представления бизнеспроцессов, которая в данный момент является для него более удобной, и работать с ней.

Возвращаясь к диаграммам деятельности отметим, что узлы диаграммы (действия) соответствуют узлам графика Workflow, а отношения между узлами (связи) – соединителям графика. Узел графика характеризуется также исполнителем данного действия; на диаграмме такой исполнитель соответствует конкретной дорожке. Однако, дорожка может соответствовать как отдельному исполнителю, так и производственному подразделению, а исполнитель в узле графика Workflow соответствует автоматизированному рабочему месту. Это важное различие требует установления определенных правил перехода от диаграмм деятельности к графикам Workflow. В качестве таких правил можно сформулировать следующие.

1. К диаграммам – прототипам графиков Workflow можно переходить только после определения состава автоматизированных рабочих мест (АРМ), имеющих возможность работы с механизмами Workflow PDMсистемы и состава специалистов ТПП, имеющих доступ к этим АРМ.

2. Каждая дорожка диаграммы – прототипа должна соответствовать специалисту (конструктору, технологу, нормировщику, начальнику отдела и т.д.), участвующему в управлении процессами ТПП с использованием данного АРМ.

3. Если имеющий АРМ специалист является руководителем группы исполнителей, не имеющих доступа к средствам Workflow (например, начальник КБ оснастки, состоящего из 5 конструкторов, не имеющих доступа к этому АРМ), то его функции на диаграмме деятельности соответствуют функциям всей группы.

Данные правила учитывают возможность самых разнообразных конфигураций средств САПР (CAD/CAE/CAM) и средств Workflow PDMсистемы для управления процессами ТПП. Например, возможны следующие конфигурации:

• все сотрудники подразделения ТПП (например, КБ оснастки) используют на своих местах PDM и CAD-систему, но средства Workflow установлены только на компьютере начальника КБ;

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

Из сказанного выше не следует, что диаграммы деятельности разрабатываются только с целью последующего составления графиков управления производственными заданиями. На начальных этапах детализации функционального описания системы их основная цель состоит в анализе предметной области с целью принятия организационно-технических решений и проведения оптимизации бизнес-процессов ТПП. Так, на основании функциональных процессов проектирования оснастки может быть проанализирован состав решаемых задач и принято решение о выборе используемых в составе АСТПП CAD/CAM и САЕ-систем, а также определено необходимое количество автоматизированных рабочих мест.

Отметим, что в ряде случаев имеет смысл описывать в диаграммах деятельности те процессы, которые реализованы “внутри” уже выбранных базовых систем. Например, если выбранная CAD-система обеспечивает автоматизированное сквозное решение всех вопросов проектирования формообразующей оснастки и инструмента (построение формообразую-щих поверхностей на основании модели изделия, построение формообразующих элементов оснастки, проектирование конструкции пресс-формы с использованием стандартных деталей, проектирование электродов для прошивной электроэрозионной обработки, получение всей необходимой чертежно-конструкторской документации), то следует описать эти функции на уровне диаграммы деятельности, так как перечисленные функции могут быть разделены между разными исполнителями. В других случаях, когда процесс выполняется одним специалистом, построения диаграммы не требуется В качестве примера можно привести проектирование в САМсистеме операции обработки детали на фрезерном станке с ЧПУ. Хотя нетрудно описать процесс такого проектирования с помощью диаграммы деятельности, в этом описании нет смысла, так как нет необходимости в его последующей программной реализации (он уже реализован в САМсистеме).

Рис. 9.7 Диаграмма совместной работы при проектировании и инженерном анализе Зависимость ряда диаграмм деятельности от выбранных базовых программных средств можно проиллюстрировать примером на рис. 9.7.

Здесь предполагается, что построение модели изделия и получение конструкторской документации (КД) выполняется в CAD-системе одним специалистом, а задачи инженерного анализа проектируемого изделия решаются другим специалистом в САЕ-системе. Данная диаграмма выявляет последовательность работ и формы обмена информацией, поэтому она может быть использована для реализации управления процессом выполнения работ в PDM-системе средствами Workflow. Если же предположить, что функции проектирования и инженерного анализа решаются одним специалистом в выбранной CAD-системе (точнее, CAD/CAE/CAM) – например, выбрана система CATIA соответствующей конфигурации – то необходимость в приведенной диаграмме отпадает, так как нет необходимости в ее программной реализации.

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

Удобство перехода от диаграмм деятельности к графикам Workflow иллюстрирует преимущества использования диаграмм UML по сравнению с диаграммами IDEF0, преобразование которых в графики Workflow не столь очевидно. Отметим, что переход от диаграмм классов UML к классификации объектов средствами PDM-системы также не вызывает затруднений, что еще раз подтверждает эффективность использования графического языка UML при построении АСТПП.

10. Ведение конструкторских и технологических проектов в среде PDM-системы Каждый проект основного изделия сопровождается в АСТПП конструкторскими проектами (КПр) изделий ТПП (НСО, оснастка, инструмент) и разработанными ТП изготовления основного изделия, которые можно назвать технологическими проектами (ТПр). Для обозначения всей совокупности конструкторских и технологических проектов ТПП для основного изделия введем аббревиатуру КТПр.

Так как описания КТПр хранятся в ЕИП ТПП, реализуемом средствами PDM-системы, необходимо установить такие процедуры ведения КПр и ТПр в среде PDM, которые бы не зависели от других систем, используемых для автоматизации конструкторского и технологического проектирования (CAD/CAM, CAE, САПР ТП и др.). Эти процедуры, встроенные в PDM-систему, обеспечивают работу специалистов в ЕИП ТПП и являются его неотъемлемой частью.

Ведение конструкторских проектов. В п. 8 было отмечено, что КПр описывается своей конструкторской документацией, к которой относятся модели, чертежи и текстовые документы. При этом, если создание моделей и чертежей является прерогативой CAD-систем, то формирование текстовых документов наиболее целесообразно выполнять в среде PDMсистемы. Это обусловлено с одной стороны тем, что в PDM содержится необходимое для их генерации полное описание структуры и содержания проекта, а с другой – тем, что эти документы должны являться частью ЕИП. Кроме того, при таком решении АСТПП не будет зависеть от наличия или отсутствия в используемой CAD-системе специальных приложений, выполняющих генерацию текстовых документов в соответствии с ЕСКД.

Необходимым условием ведения КПр в ЕИП является интеграция используемых CAD-систем с PDM-системой. Такая интеграция должна включать:

1. Привязку к КПр имени используемой CAD-системы с целью ее вызова из PDM-системы при работе с 3D моделью или чертежом изделия;

2. Привязку сгенерированного CAD-системой файла с 3D моделью или чертежом к соответствующему объекту классов “3D модели” и “Чертежи” (см. рис. 8.1);

3. Передачу атрибутной информации об объекте из PDM в CAD-систему и обратно.

Первый и второй элементы интеграции обеспечиваются введением атрибутов “Имя CAD-системы” в набор атрибутов класса “Проект изделия” и атрибута “Имя файла” в наборы атрибутов соответствующих классов. Третий элемент интеграции требует наличия в PDM и CAD системах специальных интерфейсов. Так например PDM SmarTeam имеет интерфейсные модули интеграции с CAD-системами CATIA, Pro/Engineer, SolidWorks и др.

PDM SmarTeam взаимодействует с интегрированными с ней CADсистемами посредством выполнения следующих функций:

• автоматический вызов CAD-системы из SmarTeam с передачей файла для проектирования 3D-модели или для создания чертежа;

• автоматическая передача информации из SmarTeam в основную надпись чертежа, проектируемого в CAD-системе;

• автоматический вызов SmarTeam из CAD-системы для передачи файлов 3D-моделей с регистрацией 3D-моделей, если они первично созданы в CAD-системе (т.е. передача в SmarTeam дерева сборки);

• автоматическая передача информации из основной надписи чертежа, созданного в CAD-системе, в SmarTeam.

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

После окончания ввода осуществляется передача этих данных в CAD-систему, в которой выполняется процесс создания 3D моделей и чертежей изделия. По завершении данные о составе и структуре изделия передаются в PDM-систему, которая принимает их и преобразует в соответствии со структурой базы данных ЕИП (рис. 10.1). После этого в PDMсистеме выполняется формирование комплекта текстовых конструкторских документов. Общая схема такой работы изображена на рис. 10.2.

Преобразование структуры проекта в PDM-системе заключается в том, что все входящие в состав объекты размещаются (при сохранении связей между ними) в соответствующих им классах “Сборочные единицы”, “Детали”, “Модели”, “Чертежи”, “Стандартные изделия” и др. Визуально структура проекта отображается на экране компьютера в его левой части.

Отметим, что данное преобразование структуры проекта (как и формирование текстовых конструкторских документов) не является “штатной” функцией PDM-системы, а реализуется в виде специального приложения PDM средствами API.

Рис. 10.1 Структура дерева проекта в PDM SmarTeam Для оперативного просмотра и анализа характеристик 3D модели изделия PDM SmarTeam включает набор специальных программ – просмотрщиков, которые реализуют просмотр более 250 форматов файлов.

Работа в режиме такого просмотра (рис. 10.3) не требует использования CAD-системы, что важно для управленческого персонала ТПП, а также для работы с проектом на других этапах ЖЦИ. При просмотре можно масштабировать и вращать изображение объекта, делать сечения, выполнять линейные и угловые измерения, рассчитывать площадь, изменять освещение модели.

Работа в CAD-системе при создании 3D моделей и чертежей не означает, что на данном этапе ведения КПр отсутствует управление процессами проектирования средствами PDM. Проектные работы инициируются и управляются соответствующими графиками Workflow, которые могут быть достаточно “объемными” при коллективном параллельном проектировании сложных изделий.

Pages:     | 1 |   ...   | 12 | 13 || 15 | 16 |   ...   | 18 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.