Применение ИПИ-технологий в задачах обеспечения качества и конкурентоспособности продукции (1044306), страница 9
Текст из файла (страница 9)
Здесь КИ-0 – концепция изделия, содержащая общие требования к семейству изделий.ОК 01 …ОК 0n представляют описания функциональных конфигураций модификаций и исполнений изделий, входящих в класс КИ-0, т.е. структурированные и идентифицированные наборытребований к модификациям и исполнениям (ОК высшего уровня).
Эти наборы одним из описанных выше двух способов декомпозируются на «поднаборы», относящиеся к функциональным компонентам и идентифицированные какОК 0j -1 … ОК 0j - m (j = 1…n).На схеме число «поднаборов» - одинаковое для каждого образа функциональной конфигурации, хотя, строго говоря, это не всегда так, поскольку помимо основного комплекта компонентов в отдельные конфигурации могут входить дополнительные опции, однако сути дела этоне меняет.Некоторые компоненты могут быть элементами своих классов, т.е. быть ОК, относящимися к своим КИ (КИ-1, КИ- m). На схеме ОК каждого уровня относятся к одному классу (например, все автомобили семейства ВАЗ 2110 оснащаются только бензиновыми двигателями),что, впрочем, совершенно не обязательно.
Другие же могут изначально не принадлежать известному классу и требуют специальной разработки. Для них соответствующий «поднабор»требований должен быть подвергнут дальнейшей декомпозиции (см. ОК 03-k).Документированный результат описанного выше процесса образует множество функциональных конфигураций изделий, относящихся к семейству изделий, порожденному однойКИ.После того, как в контакте потребителя и разработчика подобная структура, связанная сформированием, декомпозицией и идентификацией требований, отображена соответствующейИМ, необходим переход в конструкторский контекст, т.е.
выбор и принятие конструкторскихрешений, результатом чего является новая ИМ, отображающая проектную конфигурацию.35В состав такой ИМ входят специальные информационные объекты, определяющие конкретное конструкторское решение, соответствующее идентифицированному в ОК набору требований. Если для компонента изделия (модификации, исполнения) существуют готовые решения (имеющиеся в продаже или ранее спроектированные), то задача сводится к поиску подходящего варианта в соответствующей базе данных (каталоге, архиве и т.п.). При этом данные,содержащиеся в ОК, служат поисковым образом.
Результат поиска может оказаться не единственным. В этом случае придется либо задавать дополнительные требования (т.е. корректировать ОК), либо (при равноценности найденных решений) воспользоваться правилами применяемости, либо принимать волевое решение.КИ-0ОК 01ОК 02ОК 03ОК 0jОК0nКИ-1ОК01-1ОК02-1ОК03-1ОК0n-1ОК01-2ОК02-2ОК03-2ОК0n-2ОК01-kОК02-kОК03-kОК0n-kОК01-mОК02-mОК03-mОК0n-mКИ-mРис. 3.5. Представление конфигураций в семействе изделий.Если готовых решений нет, то начинается процесс проектирования отсутствующих компонентов, в ходе которого описанная выше процедура может быть применена к компонентамнизшего уровня (см.
рис. 3.5).Таким образом, на множестве ИМ, создаваемых на последовательно сменяющих другдруга стадиях ЖЦ (и в различных контекстах), устанавливается и прослеживается соответствиемежду деревом требований и конструкторским деревом изделия (т.е. между функциональной ипроектной конфигурациями). Иными словами, обеспечивается согласование требований и фактических свойств изделия, что и является основным смыслом технологии УК.Сформированная описанным способом, документированная и утвержденная в установленном порядке проектная конфигурация приобретает статус ПБК.Здесь следует отметить несколько важных обстоятельств.1.Число уровней в дереве требований, как правило, не слишком велико.
В частности (рис. 3.2, 3.4) это дерево может иметь одну общую вершину и один уровень конечных вершин (т.е. быть «звездным» графом). Конструкторское (проектное) дерево должно иметь такоечисло уровней, которое полностью (до деталей) описывает изделие.2.Вершины дерева требований помечаются идентификаторами, соответствующимиклассам (подклассам, группам) компонентов. Метки вершин конструкторского дерева должны36содержать обозначения (номера) конструкторских документов, в соответствии с которыми этикомпоненты могут быть изготовлены.3.Некоторые требования (например, общая масса автомобиля в табл. 3.1) изначально не всегда могут быть декомпозированы применительно к ОК, входящим в состав дерева требований.
Зато в конструкторском дереве с любой его вершиной может быть ассоциирована соответствующая характеристика (масса), так что непосредственным суммированием по деревуможет быть найдена общая масса изделия и установлено, выполняется или не выполняется требование.4.Все описанные выше и другие графы, порождаемые в процессе проектирования, исвязанные с их вершинами и ребрами объекты (характеристики, документы, правила и т.д.)отображаются последовательностью развивающихся и уточняемых ИМ. Технология УК позволяет воздействовать на этот процесс таким образом, чтобы обеспечить сближение (в пределахдопуска) требований и фактических свойств изделия и ОК.3.1.4.
Сценарии управления конфигурациейПрактическое применение технологии УК зависит от конкретной организационнопроизводственной ситуации. Рассмотрим некоторые из таких ситуаций.1. Базовое изделие и его разновидности (модификации и исполнения), т.е. семейство, ужесозданы и выпускаются в серийном, крупносерийном или даже массовом производстве (характерный пример – автомобили). Кроме основного семейства в производстве (основном илисмежном) освоены дополнительные компоненты, которые могут устанавливаться на все илинекоторые разновидности семейства по заказу потребителя (покупателя). Для этих дополнительных компонентов разработчик заранее предусмотрел посадочные (установочные) места,электрические присоединения и т.п., т.е., по существу, правила и возможности совместимостиэтих дополнительных компонентов с изделиями семейства. Информация о семействе хранится вPDM-системе разработчика и производителя (оптимальный способ такого хранения – предметотдельного рассмотрения).
Там же хранится информация о дополнительных компонентах.Потребителю в этом случае информация об изделиях семейства и дополнительных компонентах предоставляется в форме каталогов, бланков заказа и других подобных документов,на основе которых он сопоставляет свои требования с возможностями поставщика (производителя) и делает тот или иной выбор.Управление конфигурацией в описанной ситуации является внутренним делом производителя и разработчика (в частности – службы (системы менеджмента) качества).Задачи управления конфигурацией при этом состоят в следующем:периодически проверять соответствие выпускаемых изделий общим требованиями конкретным требованиям, относящимся к модификациям и исполнениям (аудит конфигурации - выполняется подразделением УК в составе службы качества);изучать предложения маркетинговой службы и службы качества (по рекламациями иным претензиям потребителей) в части совершенствования базы, моделей семейства и дополнительных компонентов и, при необходимости и целесообразности, инициировать внесениеизменений в конструкции с последующим их отслеживанием в проектировании и в производстве;обеспечивать своевременную подготовку сопроводительной документации на изменяемые компоненты и т.д.;при запуске в производство партий изделий семейства (или отдельных экземпляров) обеспечивать комплектность и актуальность рабочей конструкторской документации(РКД) и т.д.2.
Существует базовое изделие (база) и набор дополнительных компонентов. Разработаны технологии, основные виды технологической оснастки и т.д. И база, и все компоненты хотябы один раз были изготовлены. Изделия выпускаются малыми партиями или даже индивидуально по заказам потребителей. Для большинства дополнительных компонентов проработаныустановочные места, присоединительные размеры, электрические и гидравлические соединения37и т.д. Информация о базе, дополнительных компонентах, ранее выпущенных экземплярах изделий и связанной с ними документации хранится в PDM-системе предприятия.Потребителю доступна информация о характеристиках базы и дополнительных компонентов.
При заказе изделия (партии) потребитель на основе этой информации формулируетсвои требования, которые могут быть четырех видов:2.1Не требовать изменений базы и дополнительных компонентов, а касаться толькокомплектации изделия имеющимися компонентами.2.2Требовать внесения изменений в базу без изменения дополнительных компонентов, которые выбираются из имеющегося набора.2.3Требовать разработки отсутствующих дополнительных компонентов без изменения базы.2.4Требовать изменения базы и разработки отсутствующих дополнительных компонентов.В этой ситуации служба УК включается в работу на стадии подготовки контракта.В случае 2.1 служба УК должна:найти в PDM-системе предприятия вариант изделия, наиболее близкий (по составу дополнительных компонентов) к требованиям заказчика;согласовать с конструкторской службой возможности и сроки подготовки нужного комплекта документации;выдать информацию финансово-экономическим службам для расчета контрактной цены;после заключения контракта обеспечить передачу требуемого комплекта РКД впроизводство;после завершения изготовления изделия убедиться в его соответствии (по составукомпонентов) контрактным требованиям и обеспечить подготовку необходимого комплекта сопроводительной документации;убедиться в том, что данные об изделии внесены в PDM-систему предприятия ит.д.В случае 2.2 служба УК должна:выступать посредником между разработчиками и заказчиком при переговорах отехнических и юридических возможностях (в смысле изменения разрешений, сертификатов ит.д.) внесения требуемых заказчиком изменений в базу;при положительном завершении переговоров – участвовать в разработке ТЗ навнесение изменений в базу, отслеживать его реализацию в проектировании и производстве;в остальном - см.
случай 2.1.В случае 2.3 служба УК должна:выступать посредником между разработчиками и заказчиком при переговорах отехнических и юридических возможностях (в смысле изменения разрешений, сертификатов ит.д.) разработки дополнительных компонентов;при положительном завершении переговоров – участвовать в разработке ТЗ насоздание нового компонента (включая возможности его сопряжения с базой), отслеживать егореализацию в проектировании и производстве;внести сведения о новом дополнительном компоненте в перечень компонентов,предлагаемых заказчикам;в остальном - см. случай 2.1.В случае 2.4: см. случаи 2.2 и 2.3.Во всех описанных выше ситуациях и случаях служба УК – служба управления конфигурацией поставщика (разработчика).Однако, в соответствии с представлениями зарубежных нормативных документов, могутсуществовать и принимать участие в описанных процессах и процедурах службы УК заказчика(в первую очередь, для изделий, заказываемых и поставляемых для государственных нужд, вт.ч.