Управление конфигурацией : задачи, стандарты и реализация

[DGroot 8]

Предлагаю обменяться мнениями на тему об управлении конфигурацией

Затравкой для беседы может послужить статья <noindex>http://www.cadcamcae.lv/hot/Config_man_n28_p30.pdf</noindex>

Что это за зверь такой? Может уже кому-нибудь удалось обуздать этого "зверя"?

[ExtraRight 1]

Любопытно слышать таким образом заданный вопрос (как о чём-то потустороннем) от как минимум пользователя, а может и внедренца Windchill'а.

Неужель это так в Windchill'е сильно зарыто? И есть ли оно там?

[Странник 6]

Предлагаю обменяться мнениями на тему об управлении конфигурацией

Затравкой для беседы может послужить статья <noindex>http://www.cadcamcae.lv/hot/Config_man_n28_p30.pdf</noindex>

Что это за зверь такой? Может уже кому-нибудь удалось обуздать этого "зверя"?

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

[askn 0]

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

Прошу уточнить.

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

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

И что важно, в таких случаях, как правило, люди склонны не признавать, что имеется нарушение ЕСКД.

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

Изменено 26 июня 2008 пользователем askn

[suslad 1]

Неужель это так в Windchill'е сильно зарыто? И есть ли оно там?

В 9-ке это "штатная" функциональность.

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

Пожалуй все перечисленное это больше возможности CAD системы нежели конфигуратор.

Сам конфигуратор предполагает наличия в ЭСИ всех возможных вариантов взаимозаменяемых деталей, узлов. (Так реализовано в знакомых мне системах -- Search, Omega, Windchill). Между компонентами описываются взаимосвязи (обычно используется специальный интерфейс). Эта работа выполняется (или должна выполняться) ведущим конструктором или "специально обученным человеком" под бдительным оком все того же ведущего (без него никак). А вот пользоваться конфигуратором будет подразделение занимающееся сбытом изделий -- т.е. будет формироваться заказ под определенного клиента (здесь брезжит переход от "плановой экономики" к позаказному планированию). Код заказа добавляется к коду изделия чтобы получить уникальный код (аналог исполнения в ЕСКД -- только "на лету" и без необходимости постоянно лопатить ворох спецификаций с десятками исполнений).

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

[Странник 6]

....

Пожалуй все перечисленное это больше возможности CAD системы нежели конфигуратор.

Сам конфигуратор предполагает наличия в ЭСИ всех возможных вариантов взаимозаменяемых деталей, узлов. (Так реализовано в знакомых мне системах -- Search, Omega, Windchill).

....

Э нет, создавать версии (аналог номера измнения в ЕСКД) CAD не в силах, тут ужо PLM должна работать по полной программе и непременно с Workflow.

Кстати, за Windchill не скажу, а вот двум другим названным системам до названного функционала, пожалуй, надо бы ещё не слегка подрости.

[suslad 1]

Э нет, создавать версии (аналог номера измнения в ЕСКД) CAD не в силах, тут ужо PLM должна работать по полной программе и непременно с Workflow.

Все верно. Создавать и контролировать версии документов дело PLM-систем.

Кстати, за Windchill не скажу, а вот двум другим названным системам до названного функционала, пожалуй, надо бы ещё не слегка подрости.

Каждый выбирает то что ему подходит.

[ExtraRight 1]

Пожалуй все перечисленное это больше возможности CAD системы нежели конфигуратор.

Сам конфигуратор предполагает наличия в ЭСИ всех возможных вариантов взаимозаменяемых деталей, узлов. (Так реализовано в знакомых мне системах -- Search, Omega, Windchill). Между компонентами описываются взаимосвязи (обычно используется специальный интерфейс). Эта работа выполняется (или должна выполняться) ведущим конструктором или "специально обученным человеком" под бдительным оком все того же ведущего (без него никак). А вот пользоваться конфигуратором будет подразделение занимающееся сбытом изделий -- т.е. будет формироваться заказ под определенного клиента (здесь брезжит переход от "плановой экономики" к позаказному планированию). Код заказа добавляется к коду изделия чтобы получить уникальный код (аналог исполнения в ЕСКД -- только "на лету" и без необходимости постоянно лопатить ворох спецификаций с десятками исполнений).

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

ув. suslad, всё очень правильно описали. Небольшие уточнения от автомобилестроителей :

Маркетинговый конфигуратор и конструкторский обычно оперируют разными опциями, только они связаны между собой связями типа 1-1 и 1-n

EBOM - дерево, куда входят все компоненты для всех конфигураций, при задании всем опциям определённых значений - EBOM фильтруется до получения BOM конкретной конфигурации

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

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

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

[Странник 6]

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

[askn 0]

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

Вот это как раз и хотелось бы видеть в ЕСКД - общую терминологию и общие форматы представления данных.

Я постарался в предыдущем посте по этой теме указать на недостаточность ЕСКД в вопросе конфигурируемости изделий. Никто не возразил, но и не поддержал. Кто как трактует ЕСКД по этому вопросу?

Изменено 26 июня 2008 пользователем askn

[suslad 1]

Я постарался в предыдущем посте по этой теме указать на недостаточность ЕСКД в вопросе конфигурируемости изделий. Никто не возразил, но и не поддержал. Кто как трактует ЕСКД по этому вопросу?

Насколько я знаю в ЕСКД не расписан конфигуратор вообще как таковой. ЕСКД оперирует только исполнениями и модификациями.

В этом плане лучше посмотреть ISO10303. На базе этого документа построены буржуйсткие PLM-системы (ИМХО).

[ExtraRight 1]

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

Прошу прощения, но я в своём посте не использовал ни одного термина CATIA

Возможно Вас смутил термин EBOM, но он достаточно общепринятый для PDM систем

EBOM - Engineering Bill of Materials, Engineering BOM - т.н. конструкторский иерархический состав изделия, сейчас принято включать в него компоненты всех конфигураций (вариантов) изделия. Состав кокретной конфигурации ( определяемой конкретным набором совметимых значений опций) получается фильтрацией EBOM

Если есть недопонимание каких-нибудь ещё терминов, то хотя бы намекните на них

[EYKD 0]

В этом плане лучше посмотреть ISO10303. На базе этого документа построены буржуйсткие PLM-системы (ИМХО).

Если говорить про ISO, то стандартом по управлению конфигурацией является стандарт ISO10007. ICM, Институт Управления Конфигурацией, упомянутый в статье по ссылке в первом посте темы, разработал свой стандарт <noindex>CMII-105</noindex>, который не противоречит ISOшному, а развивает и дополняет его.

На практике управление конфигурацией продукта осуществляется в PDM системах примерно так, как об этом написали suslad и ExtraRight. В разных системах и на разных предприятиях всегда будут свои особенности, но общий принцип таков: в дереве продукта существуют различные варианты реализации опциональных элементов изделия; конфигурация конкретного изделия получается путём наложения фильтра. Параметры у фильтра могут быть самые разные: серийный номер, номер опции и т. д.

Изменено 28 октября 2010 пользователем EYKD

[Странник 6]

На самом деле главный вопрос о конфигурациях изделия суть проблемы правильной структуризации базы знаний предприятия и функциональных возможностей поисковика. Особо остро это ощущается в случае массового применения покупных элементов вообще и радиоэлементов в частности. Глобальных заморочек пока видится четыре:

1. где взять 3D-модель покупного элемента?

2. как правильно определить потребный для 3D-модели покупного элемента набор атрибутов?

3. как организовать межэлементный пересчёт выходных параметров во входные?

4. кто собственно всё это будет делать?

Упрощенный пример.

Завод Э массово выпускает электродвигатели типов Э1, Э2 и Э3, то бишь есть матчасть и ТУ в формате pdf. Фабрика П массово выпускает пропеллеры типов П1000, П1001 и П1002, тоже матчасть и ТУ в формате pdf. Габаритные чертежи, таблицы модификаций, важнейшие с точки зрения производителя параметры продукции и т.п в ТУ прописаны по всем правилам ЕСКД. Однако мне то нужны габаритные 3D-модели, с точным соответствием инерционно-массовых характеристик, посадочных и стыковочных мест, кинематики, электрики и т.п. Стало быть вопросы №№1,2.

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

Можно конечно попытаться использовать логические правила, но поди угадай какие именно атрибуты нужно будет считывать -> преобразовывать -> сравнивать в каждом конкретном случае из миллиона. Стало быть вопрос №4.

P.S. а разработчики элементной базы постоянно обновляют свои модельные линейки.

[trion 0]

1. где взять 3D-модель покупного элемента?

2. как правильно определить потребный для 3D-модели покупного элемента набор атрибутов?

3. как организовать межэлементный пересчёт выходных параметров во входные?

4. кто собственно всё это будет делать?

Покупной элемент в натурном виде можно отсканировать 3D сканером, можно попросить 3D каталог у производителя, можно отмоделить.

Например, покупные болты и гайки даже не стандартные - проще отмоделить.

[EYKD 0]

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

Причём тут 3D-модели ПКИ, если управление конфигурацией осуществляется на бумаге (в виде документов), и в PDM-системе? Причём тут согласование характеристик покупных элементов, если это задача конструктора?

Зачем что-то выдумывать, если существует нормативная база по управлению конфигурацией, а именно <noindex>ГОСТ ИСО 10007</noindex>, который идентичен международному стандарту ISO 10007?

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

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

В другом месте стандарта даётся более простое определение управления конфигурацией: Скоординированные действия, направленные на формирование и контроль конфигурации.

Управление конфигурацией включает в себя 5 задач:

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

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

a. Структура продукции и выбор элементов конфигурации;

b. Данные о конфигурации продукции; и last but not the least

c. Базовая конфигурация.

3) Управление изменениями. Выполнение этой задачи состоит из инициирования, идентификации, оценки, выполнения и верификации изменений.

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

5) Аудит конфигурации. Аудит конфигурации должен быть выполнен в соответствии с зарегистрированными процедурами для определения соответствия продукции установленным требованиям и данным о конфигурации продукции.

Изменено 4 ноября 2010 пользователем EYKD

[Странник 6]

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

Причём тут 3D-модели ПКИ, если управление конфигурацией осуществляется на бумаге (в виде документов), и в PDM-системе? Причём тут согласование характеристик покупных элементов, если это задача конструктора?

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

Связано это с тем, что цепочка создания новой техники выглядит примерно так:

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

Расскажите уж, как и чем будете заменять в находящемся на этапе послепродажного обслуживания изделии АБВГ.00.00.000 прибор "ЯЩИК-7"? Небось просто на письме заказчика от руки напишите резолюцию

Прибор заменить к утру!

и всё будет просто замечательно?

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

Уважаемый коллега Джонни.

В ответ на ваш исходящий №.../... сообщаю, что в связи с прекращением производства прибора "ЯЩИК-7" ещё 10 лет тому назад запрошенный вами ремонт невозможен.

Предлагаю следующие варианты решения вашей проблемы:

1. срок1/цена1/качество1

2. срок2/цена2/качество2

3. срок3/цена3/качество3.

С уважением.

Прохор.

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

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

Как говорят в авиации:

Хочешь летать безопасно? Учи матчасть!

[EYKD 0]

EYKD, лучше вам было оставить свои мнения о участниках форума при себе. Ведь сейчас окажется, что матчасти вы не знаете совершенно. Признавайтесь сразу, сами то хоть что ни будь проектировали?

Нет, сам ничего не проектировал. А что вы имеете в виду под матчастью? 50 лет опыта черчения на кульмане по ЕСКД? Но современный мир ушёл немножко дальше.

Кстати, первые стандарты по управлению конфигурацией появились ещё в 60-е годы по инициативе Министерства Обороны США.

Кто кроме конструктора вообще может принять решение о конфигурации изделия? Наверное менегер, а может заказчик?

Заказчик является источником требований к конфигурации. А принять решение о конфигурации изделия может менеджер по управлению конфигурацией. Ну или начальник департамента по управлению конфигурацией. Или заместитель главного конструктора по управлению конфигурацией. Название не принципиально, важно, что в организации есть такая функция.

цепочка создания новой техники выглядит примерно так: конструкторская документация (КД) -> технологическая документация (ТД) -> организационнно-распорядительная документация (ОРД).

Ничего не перепутали? Причём тут вообще ОРД? Может быть, эксплуатационная документация (ЭД)?

Организационно-распорядительная документация классифицируется на три группы:

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

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

- организационная документация (уставы, положения, правила, инструкции, штатные расписания).

Расскажите уж, как и чем будете заменять в находящемся на этапе послепродажного обслуживания изделии АБВГ.00.00.000 прибор "ЯЩИК-7"?

Простите, а причём здесь ППО в целом и описанная ситуация в частности?

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

[Странник 6]

Нет, сам ничего не проектировал.

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

Именно по этой простой причине последнее слово в технической дискуссии всегда остаётся за конструктором.

Заказчик является источником требований к конфигурации. А принять решение о конфигурации изделия может менеджер по управлению конфигурацией. Ну или начальник департамента по управлению конфигурацией. Или заместитель главного конструктора по управлению конфигурацией. Название не принципиально, важно, что в организации есть такая функция.

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

Ничего не перепутали? Причём тут вообще ОРД? Может быть, эксплуатационная документация (ЭД)?

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

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

[PeterShilnikov 1]

...

1. где взять 3D-модель покупного элемента?

2. как правильно определить потребный для 3D-модели покупного элемента набор атрибутов?

...

Я бы это отнес к проблеме классификаторов (библиотек изделий). Это где-то пересекается, но не полностью... Есть вообще-то стандарт ISO 13584 PLIB, который предназначен для решения этих задач, но информации о реальном его применении у меня нет. Единственное, что я читал несколько лет назад в ответе одних разработчиков софта: "О, да, конечно, наш PLIB самый лучший в мире, и US Navy пользуется только им". Наверное, все-таки где-то кем-то он используется.

Также решается эта задача в рамках ISO 15926 OIL&GAS, там предусматривается некая всеобщая база изделий с XML-интерфейсом, но это - стандарт, ориентированный на специфическую область, хотя многие его положения на самом деле инвариантны к предметной области и могут быть использованы где угодно.