Как вы документируете свои решения по проектированию оборудования?


43

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

  • Почему выбрали этот компонент?
  • Почему / как я выбрал эти конкретные параметры для этого компонента?
  • Что делает эта часть схемы?
  • Что такое рассеиваемая мощность через этот компонент?
  • Какова общая потребляемая мощность этой цепи?
  • Могу ли я заменить этот компонент другим? Есть ли эквивалентные компоненты для этого компонента? и т.п.

Как правильно документировать ваши решения и расчеты на этапе проектирования схемы? Как получить ответы на поставленные выше вопросы, не просматривая сотни страниц с таблицами данных?

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


1
Кто увидит эти детали? Они только для вашей справки или их увидят другие?
Станри

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

9
@ Стейси Но на самом деле .. какая разница? Через некоторое время вы будете смотреть на свой собственный дизайн так, как если бы вы видели его впервые ...
м.Алин

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

4
OMG, я люблю этот вопрос. (извините, я знаю, что это не очень помогает, но я сейчас над этим работаю, так что это здорово). Продолжать.
efox29

Ответы:


15

Я лично иду по старомодному пути: у меня есть записная книжка, где я записываю абсолютно все о принимаемых мной дизайнерских решениях. Особенно выбор компонентов и стоимости, текущие расчеты, расчеты электропитания, все. Я также документирую решения по программному обеспечению / программно-аппаратным средствам и замечания о времени и использовании ресурсов.

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

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

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


Полностью согласен с вопросом о формулах, но я перестал использовать бумажные заметки около 5 лет назад. Typing гораздо проще , чем писать, и имеет все обычные электронные текстовые преимущества - для поиска, sendable, backupable и т.д.
Markt

2
Некоторые из самых впечатляющих / важных дизайнерских ноутбуков нашего времени: computerhistory.org/collections/fairchild . Одним существенным преимуществом бумажного журнала / тетради является рисование. На моем ноутбуке требуется значительно больше усилий для рисования / рисования эскизов (хотя на iPad это проще - моя жена, например, хранит свои заметки о дизайне на своем iPad). Я склонен мыслить графически, поэтому я много делаю, рисуя блок-схемы.
Slebetman

11

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


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

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

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

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

Все спецификации, PRD, MRD хранятся в SVN со ссылками на документы на внутренней вики. Изменение спецификации приведет к обновлению SVN и уведомлению заинтересованных сторон. Конечно, вы можете просто держать его вручную в общей папке.

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


Хорошо, возможно, я должен был также обратиться к каждому вопросу :)

Если вы делаете расчеты, в Excel, может быть? Или на бумаге, и вы думаете, что результаты и метод важны для понимания и проектирования вашей схемы, тогда вы должны включить их в соответствующий раздел спецификации проекта. Даже если это означает, что нужно сделать снимок вашего рисунка руки :)

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

Почему / как я выбрал эти конкретные параметры для этого компонента? Объедините это с выше.

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

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

Какова общая потребляемая мощность этой цепи? Я думаю, что это относится к блоку питания вашей спецификации.

Могу ли я заменить этот компонент другим? Есть ли эквивалентные компоненты для этого компонента? и т.д. Это, я думаю, принадлежит вашей спецификации или любому другому процессу, который вы используете для производства. Альтернативные части должны облегчить поиск. Опять же, для нас это все из базы данных запчастей.


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

1
@ m.Alin SHG, похоже, работает как я, и у него есть документ спецификации, который готовится перед работой над схемой. Этот документ должен содержать подробные требования к схеме, информацию об общей системе, обоснование основных решений и т. Д. В нем документируется ваш мыслительный процесс и перечисляются требования, которые вы затем можете принять для разработки своей схемы. Это способ работать в профессиональной обстановке, но вы можете уйти с ноутбуками и т.п., если вы занимаетесь дизайном дома. Я обычно держу папку на своем рабочем сервере с
I. Wolfe

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

добавил несколько комментариев о нашем процессе в действии
Some Hardware Guy

4
+1 за использование контроля версий для критически важных документов. Его должен использовать каждый, даже один, работающий не по найму инженер.
Лиор Билия

5

Я занимаюсь быстрым поворотом дизайна и должен сказать: аннотирование схемы - самая удобная вещь. Для любого из моих проектов редко бывает больше 2 или 3 листов формата А4, поэтому количество дизайнерских решений ограничено. Многие дизайнерские решения в значительной степени автоматические; Мне не нужно перечислять причины для каждой части. Всего одна или две основные части и, возможно, какой-то пассивный фильтр или чувствительный датчик. Все остальное сразу бросается в глаза любому опытному инженеру-конструктору.

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

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

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


3
Обычно лучше иметь специальный документ, по крайней мере, в профессиональной обстановке. Например, если я хочу знать, почему я выбрал значение предохранителя, было бы хорошо знать, что мой выходной сигнал потребляет 700 мА для 50 мкс, а затем 300 мА для 3 с. Эта информация просто загромождает схему, где все, что вам действительно нужно поместить, это номинал предохранителя, но может понадобиться в какой-то момент. Также есть обстоятельства, когда у меня было 6 сервоприводов, работающих на одном регуляторе, и мне нужно знать, сколько двигателей будет работать одновременно. Опять что-то нужно, но не на схеме.
I. Wolfe

1
Конечно, мнения будут разными. Все, что я говорю, это то, что с 200+ дизайнами под моим поясом я нахожу, что это работает очень хорошо. «Профессионал» не обязательно означает строгий протокол и методологию; для относительно небольших проектов (что является большинством того, что я делаю) это работает хорошо. Крупные проекты и особенно совместный дизайн (который в наши дни встречается очень редко, даже такие вещи, как Raspberry Pi разрабатываются и разрабатываются одним и тем же парнем), все же требуют чуть большего количества шаблонов.
user36129

4

Для многих из моих небольших проектов я обычно размещал простую зеленую метку и границу вокруг подсхем. Для более крупных проектов некоторое программное обеспечение eCAD позволяет строить из блок-схемы вниз, где каждый лист дополнительно описывает один блок. Существует искусство разложения любой проблемы и управления компромиссами (это инженерное ИМХО). Там, где есть определенный анализ выбора компонентов, таких как аналоговая фильтрация, я отмечу частоту среза и тип фильтра (например, фильтр нижних частот (f_c = 100 Гц))

Общие блоки, с которыми я сталкиваюсь, включают:

  • Управление питанием (регуляторы напряжения, защита от переполюсовки, диоды TVS, выключатель питания, заглушки байпаса и т. Д.)
  • MCU (микроконтроллер, программный заголовок или пэды, заглушки обхода чипа)
  • Индикаторы (например, светодиоды, EL-провод, 7-сегментный дисплей, вибромотор)
  • Определение определенной функции (например, измерение тока, определение касания, GSR, активность, определение состояния окружающей среды и т. Д.)
  • Отладочные сообщения (ферритовый шарик, USB, I2C, UART, SPI, некоторый способ получить информацию)
  • Радио (все компоненты поддержки для многих радиостанций)
  • Видео (все компоненты поддержки и чипы для камеры)
  • Внешнее хранилище (например, внешняя флэш-память, микросхема EEPROM для хранения настроек и т. Д.)
  • Любая другая особенность, уникальная для вашего дизайна

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


3

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

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

Все версии всех вещей отслеживаются с помощью Subversion.

Это может быть существенным компонентом файла истории проектирования, который является обязательным для FDA.


3

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

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

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

Я также могу включить графики, нарисованные научным программным обеспечением, таким как октава.

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

Наконец, Keynotes / Powerpoints легко подгонять для других и экспортировать в формате pdf для распространения среди людей, не являющихся техническими специалистами.


3

Разместите инженерные заметки на схемах и при необходимости создайте больше листов. Я всегда размещаю инженерные заметки на всех своих схемах, потому что в моем мире мне, возможно, придется повторно посещать 1/2 запеченного дизайна на какое-то время, а затем снова ставить его на задний план, пока я подбираю другой дизайн; очень плавный расчетный поток. Эти заметки EE помогают мне и другим без особых усилий пересмотреть замысел проекта. Я также использую различные цвета текста / графики, чтобы указать важность или контекст. Пример ниже ...введите описание изображения здесь

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.