WWW.DISSERS.RU

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

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

Pages:     | 1 |   ...   | 11 | 12 || 14 | 15 |   ...   | 18 |

Рис. 8.3. Использование отношения ассоциации Отметим, что при реализации модели предметной области средствами PDM-системы отношения (связи) описываются так же, как классы – именем и набором атрибутов. Связи хранятся в базе данных как самостоятельные независимые сущности, что является следствием использования в PDM-системах реляционных СУБД.

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

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

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

Как известно, при разработке ТП определяется необходимая оснастка и инструмент. Если оснастку или инструмент нужно изготавливать, составляется соответствующая карта заказа для служб ТПП. Так как информация о заказах является “сопутствующей” информацией к ТП, то ее следует также включить в раздел “Процесс” ЕИП ТПП.

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

Рис. 8.4. Классификация раздела “Процесс” Сделаем некоторые пояснения по представлению информации в классе бизнес-процессов. Как отмечалось выше, в нотации UML формой детального представления бизнес-процессов являются диаграммы деятельности с дорожками. При детальном представлении учитываются конкретные подразделения предприятия или исполнители, а функции детализируются до уровня производственных заданий. В такой форме диаграммы деятельности могут быть непосредственно реализованы в среде PDM-системы с помощью механизмов управления потоками производственных заданий (Workflow). Однако, сама информация о производственных заданиях (функциях, операциях) и о порядке их выполнения (графиках заданий) должна быть размещена в ЕИП в виде данных, что и требует введения специальных классов в рамках статической модели предметной области.

Рис. 8.5. Ассоциативные связи классов при проектировании ТП Ресурс. Под ресурсом будем понимать различные виды обеспечения, используемые при выполнении бизнес-процессов ТПП. К таким видам обеспечения можно отнести:

• Кадровый ресурс – включает отделы, службы и цеха предприятия, их сотрудников и специалистов, участвующих в процессах ТПП;

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

• Материальный ресурс – включает используемые материалы, стандартные и покупные изделия (СИ и ПИ);

• Информационный ресурс – включает используемые при выполнении бизнес-процессов ТПП справочно-информационные материалы, такие как ГОСТы на материалы и стандартные изделия, нормативнотехнологичекие документы, а также архивы КД и ТД, находящиеся в ведении служб технической документации предприятия.

Таким образом, классификация раздела “Ресурс” будет выглядеть в соответствии с рис. 8.6.

Рис. 8.6 Классификация раздела “Ресурс” Степень дальнейшей детализации того или иного класса раздела “Ресурс” зависит от характера задач, решаемых как на этапе ТПП, так и на некоторых других этапах ЖЦИ. Например, если информация об оборудовании используется только при проектировании ТП, то достаточно ограничиться перечислением моделей станков с указанием цехов в которых эти станки размещены. Если же информация используется для организации планирования производства, обслуживания и ремонта оборудования, то необходима дополнительная классификация оборудования и достаточно большой набор атрибутов, описывающих каждую единицу оборудования.

Таким образом, ЕИП ТПП реализуется на основе единой базы данных “Продукт – Процесс – Ресурс”, которая:

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

• используется совместно конструкторами, технологами и другими специалистами предприятия при выполнении бизнес-процессов ТПП;

• допускает ее использование на других этапах ЖЦИ.

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

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

Рис. 8.7 Программные контуры и единая база данных Внутрисистемный контур представляет собой программное обеспечение PDM-системы для выполнения следующих базовых функций:

• редактирование структуры базы данных и экранных форм отображения информации;

• ввод в базу данных информации об объектах, иерархических и логических связях между объектами;

• ведение состава проектов;

• классификация объектов и наследование информации по иерархии классов;

• ведение жизненного цикла документов;

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

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

• автоматическое наращивание обозначений документов и объектов;

• регламентация прав доступа к информации;

• экспорт и импорт информации;

• составление графиков производственных заданий и отслеживание их выполнения.

Технологический контур – это набор прикладных программ (подсистем, модулей), разработанных с помощью средств программного интерфейса API PDM. Созданные прикладные программы решают такие задачи проектирования, управления и документирования в АСТПП, которые не решаются в CAD/CAM/CAE-системах и не поддерживаются “штатными” функциями PDM-системы. К этим задачам относятся: проектирование технологических процессов; разузлование изделий; расчет потребности в материалах и стандартных изделиях; формирование циклограмм сборки;

получение сводных конструкторско-технологических документов и др.

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

Внешний контур – это потребителями информации, созданной на этапе ТПП, которые обслуживают остальные этапы ЖЦИ (маркетинг, снабжение, производство, контроль, упаковка, реализация, монтаж, техобслуживание, утилизация). Рабочие места “потребителей” могут быть оснащены той же PDM, на которой реализовано ЕИП или другими системами.

Для этих систем должен существовать интерфейс с основной PDM.

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

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

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

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

На рис. 9.2 – 9.5 приведены диаграммы деятельности для основных функций ТПП, включающих: отработку изделия на технологичность; проектирование нестандартного оборудования (НСО); проектирование оснастки или средств технологического оснащения (СТО); проектиро-вание технологических процессов (ТП). Функция управления ТПП не может быть детализирована в виде одной диаграммы – она неявным образом входит во все представленные выше виды диаграмм в виде потоков управления работами по проектированию и изготовлению.

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

Однако, уровень детализации бизнес-процессов ТПП на приведенных диаграммах еще не позволяет использовать их для составления графиков производственных заданий в АСТПП, с целью непосредственной организации управления процессами подготовки производства. Чтобы проанализировать дальнейшую детализацию, необходимо более конкретно обрисовать ее конечные формы, то есть формы реализации механизмов управления потоками производственных заданий (Workflow) в PDM-системе.

Поэтому рассмотрим кратко реализацию механизмов Workflow в PDMсистеме SmarTeam.

Рис. 9.2 Диаграмма деятельности для функции ТПП “Отработка изделия на технологичность” Графики Workflow в SmarTeam визуально представляют собой совокупность узлов и соединителей, по которым информация перемещается от одного узла или состояния к другому (рис. 9.6). Узел определяет производственное задание и его характеристики. При составлении производственного задания для каждого узла указываются такие свойства, как пользователь, действия которого в рабочем процессе соответствует этому узлу графика заданий, и задание, которое он должен выполнить, а также сроки или другие условия выполнения задания. В принципе можно создавать такие узлы, задания в которых будут выполняться не пользователем, а самой системой SmarTeam (например, передача данных или выдача сообщений).

Задания бывают трех типов:

Рис. 9.3 Диаграмма для проектирования и изготовления оснастки Рис. 9.4. Диаграмма для проектирования и изготовления НСО Рис.9.5 Диаграмма для проектирования ТП • Ручное задание. Пользователь просто выполняет то, что ему предписано в этом узле, и отсылает результаты дальше.

• Операция. Пользователь должен совершить какое-либо стандартное действие, поддерживаемое системой, например, “Взять на изменение”, “Утвердить” и т. д.

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

Рис. 9.6 Визуальное представление графика Workflow в PDM SmarTeam График заданий имеет один стартовый (начальный) узел, соответствующий началу работ, и один конечный узел, достижение которого говорит о завершении выполнения графика. График описывает общую схему производственного процесса безотносительно к объекту, для которого этот процесс применяется. Например, график “Разработать сборочный чертеж” описывает схему действий безотносительно к конкретной сборочной единице.

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

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

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

Pages:     | 1 |   ...   | 11 | 12 || 14 | 15 |   ...   | 18 |



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

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