[dead_cell 0]

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

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

- УГО будут выполнены по некоторым правилам (какой стандарт это вопрос не главный).

- футпринты элементов будут оформлены по неким правилам с привлечением некоторых стандартов+некие требования по конструктиву (шелкуха там и прочие).

- можно еще придумать что нибудь.

 

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

 

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

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

или я запутался уже? :)

[vitan 2]

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

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

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

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

[dead_cell 0]

что подразумевается под понятием процесс?

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

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

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

- также параллельно, если есть необходимость, то генерится модель для MCAD;

- идет оповещение того кто запросил компонент, о том, что достигнут некий результат или не достигнут по каким-либо причинам;

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

 

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

 

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

[vitan 2]

что подразумевается под понятием процесс?

Действия по работе с компонентами.

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

 

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

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

так:

 

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

[cioma 0]

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

 

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

 

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

[vitan 2]

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

Мы говорим о разных вещах. Ответственность это одно, а качественные результаты - другое.

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

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

[dead_cell 0]

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

 

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

буду писать непосредственно в IEC, но вдруг кто сталкивался и знает.

[dead_cell 0]

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

теперь только осталось его или купить или слить.

 

есть у кого?

[Jul 0]

Позиционные обозначения - см. ГОСТ 2.710-81 "Обозначения буквенно-цифровые в электр. схемах"

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

[dead_cell 0]

Позиционные обозначения - см. ГОСТ 2.710-81 "Обозначения буквенно-цифровые в электр. схемах"

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

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

 

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