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

кто какие стандарты использует в работе для формализации процесса? (в данный момент пытаемся организовать библиотеки под новый САПР, про старое железо разговора нет)
например:
- для УГО стандарт IEC 60617
- не нашел еще пока что соглашение об именовании элементов (кто знает киньте номерок)
- для footprint, padstack - IPC7351B (размеры, именование)

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

может быть тема вообще бред?
до этого смотрел темы:
1. http://electronix.ru/forum/index.php?showt...50314&st=60
2. http://electronix.ru/forum/index.php?showt...%ED%E4%E0%F0%F2

Зря.


А чем наш-то не устроил? Не думаю, что кто-то там за бугром не поймет нашего УГО...


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


Ну да, но некоторые тоже рекомендуют свои правила именования, на практике имхо это смысла не имеет.


Это как бы в общем случае. А в реальности, если никто там про тот же IPC не слышал, то вряд ли Вы туда отправите... Т.е. имхо над этим надо задумываться в последнюю очередь.

ну не то, чтобы зря... Рисование символов по ГОСТу затруднит использование сторонних символов без их переделки. Лучше уж сразу, в том же стиле рисовать свои, тогда меньше работы в итоге будет.

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

не-не-не, партнамбер это как раз таки понятно. я про reference designator имел ввиду. микросхема U или DD, DA. кварц Q или X и т.д.
например приходит новый разработчик и начинает гнуть пальцы что он, например, работал много лет где-то там и они делали вот так то, чтобы можно было сказать, что вот на тебе наши рекомендации, там все написано. разрабатывать что то свое не хочется и потом если, например, как у нас случается схема нарисована где-то НЕВРОССИИ, то как их обязать нарисовать по ГОСТу (хотя если они рисуют "от балды", то и IEC не стандарт )?
по IPC просто есть скачанный документ и по нему удобно генерить футпринты и только. удобно править падстэки, там есть такой раздел Padstack Naming Convention, имея который удобно хранить и понимать что у тебя есть а чего нет и т.д.

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

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

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

Да как удобно, так и рисуем. Кратность между пинами соблюдаем, да пины в сетку чтобы попадали. Это для микросхем. Мелочевка вся рисована "по умолчанию", по какому-то IEC наверное, точно не скажу.
У нас просто изрядное кол-во новых элементов появляются из референс-дизайнов, ну и их оставляем как есть, поэтому и все остальное в том же стиле. Но мы даже не в России, так что нам ГОСТы вообще никак не нужны. Главное, чтобы схема читаемой была.
Вот пример одной страницы схемы:  sch_.pdf ( 561.08 килобайт ) Кол-во скачиваний: 404

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

Да ну бросьте! Кого это волнует? Все применение САПР рассчитано в первую очередь на повышение скорости и качества разработки в смысле выхода на рынок. А разные начертания вряд ли как-то на это повлияют, разве что в супертранснациональной компании, где один лист рисуют в Европе, а второй - в Азии. И то, связь как бы есть, могут и созвониться..
Другое дело - система ЕСКД, в которой предусматривается одинаковое понимание КД на разных заводах (между ними нет конкуренции). Эта система намного более прогрессивна, и Вашу ситуацию можно рассматривать как частный случай применения этой системы. Да, в ней нет стандартов типа 7351 (по объективным причинам), но схемотехническая-то часть есть. Берите ее и не пожалеете.

согласен.


вот еще нашел статью про стандартизацию в россии http://www.russianelectronics.ru/developer...2149/doc/46425/

после прочтения статьи не согласен

Скажите, я отдельного человека библиотекарем назначили? Чтобы он за все это отвечал. Иначе со стандартами или без - порядка не будет.

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

Уверены?
Вот вопрос: нарисовали схему, в которй этот человек перепутал нумерацию выводов, развели плату, спаяли - КЗ по питанию. И так на нескольких типах изделий, в которых схемотехники применили эту деталь. Кто виноват в этом (не в том, что элементы кривые, а в общем фиаско)? Библиотекарь? Не боитесь на одного человека вешать такую ответственность?
Более прогрессивный подход состоит в многоступенчатой системе проверки, при которой (это отдельный вопрос от многоступенчатости) проверка выполняется разными людьми.
Могу поэтому посоветовать не брать библиотекаря, а нормально расписать процессы внесения компонентов в базу и использования их оттуда.

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

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

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

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


Нет, не в этом. Эти правила Вы зачем-то хотите ввести. Вопрос именно в том, зачем и чего надо этим добиться.