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

кто какие стандарты использует в работе для формализации процесса? (в данный момент пытаемся организовать библиотеки под новый САПР, про старое железо разговора нет)
например:
- для УГО стандарт 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 наверное, точно не скажу.
У нас просто изрядное кол-во новых элементов появляются из референс-дизайнов, ну и их оставляем как есть, поэтому и все остальное в том же стиле. Но мы даже не в России, так что нам ГОСТы вообще никак не нужны. Главное, чтобы схема читаемой была.
Вот пример одной страницы схемы:Нажмите для просмотра прикрепленного файла

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

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

согласен.


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

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

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

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

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

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

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

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

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


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

добиться? добиться того что библиотека будет пополняться компонентами "с некоторой вероятностью это правильно" и все остальные участники будут ей пользоваться.
- УГО будут выполнены по некоторым правилам (какой стандарт это вопрос не главный).
- футпринты элементов будут оформлены по неким правилам с привлечением некоторых стандартов+некие требования по конструктиву (шелкуха там и прочие).
- можно еще придумать что нибудь.

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

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

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

что подразумевается под понятием процесс?
- у схемотехника появилось желание установить на схему (в изделие) некий компонент, которого нет в базе данных предприятия;
- посылает запрос на создание компонента, с приложением всей необходимой информации для того чтобы данный компонент оказался в базе данных;
- запрос по оговоренным правилам попадает к тому персонажу, который отвечает за то чтобы нужные атрибуты появились в базе, УГО и футпринт (по неким стандартам ) появились в базе САПРа, ;
- также параллельно, если есть необходимость, то генерится модель для MCAD;
- идет оповещение того кто запросил компонент, о том, что достигнут некий результат или не достигнут по каким-либо причинам;
- если результат устраивает заказчика, то все замечательно, запрос на создание компонента считается выполненным.

ну это в общих чертах....

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

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

Поэтому можно перефразировать уже прозвучавший вопрос

так:

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

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

А ответственным за библиотеку вцелом должен (!) быть один человек. Да, если неправильная распиновка - спрос с него лично. А уж какие у него дополнительные функции (схемотехник, конструктор итп), а также сколько еще человек вовлечены в создание компонентов и каким образом они вовлечены - это другой вопрос. Может быть так, что символ с номерами пинов рисует схемотехник (по некоторым принятым в конторе правилам), посадочное место с номерами падов создает конструктор (например, по стандартам IPC), кто-то третий проверяет распиновку, а библиотекарь ложит компонент в базу (может дополнительно проверить распиновку + автоматические проверки). Но именно библиотекарь отвечает за то, что все фазы создания компонента были пройдены, все проверки сделаны.

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

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

приподниму тему!

кто знает какой стандарт IEC (МЭК) регламентирует reference designator'ы на схеме? нашел только IEC 60027-1, но не совсем уверен.
буду писать непосредственно в IEC, но вдруг кто сталкивался и знает.

после переписки с IEC установил нужный стандарт по reference designator'ам - IEC 81346-2.
теперь только осталось его или купить или слить.

есть у кого?

Позиционные обозначения - см. ГОСТ 2.710-81 "Обозначения буквенно-цифровые в электр. схемах"
и ГОСТ 2.702-75 "Правила выполнения электрических схем", пункты 3.17, 3.18, 3.19, 3.20 и 3.28

это я в курсе. мне и моему руководству хочется чтобы графические символы и позиционные обозначения выполнялись в соответствии со стандартом IEC (МЭК) т.к. он в данный момент является наиболее продвинутым. наши ГОСТы, к сожалению, немного устарели. хотя не отрицаю их актуальность в данный момент, но если так и будет продолжаться и дальше с ГОСТами, то ничего хорошего не будет конечно.

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