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

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

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

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

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

39 голосов | спросил m.Alin 9 FebruaryEurope/MoscowbMon, 09 Feb 2015 17:30:25 +0300000000pmMon, 09 Feb 2015 17:30:25 +030015 2015, 17:30:25

7 ответов


14

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

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

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

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

ответил stanri 9 FebruaryEurope/MoscowbMon, 09 Feb 2015 18:21:05 +0300000000pmMon, 09 Feb 2015 18:21:05 +030015 2015, 18:21:05
11

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


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

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

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

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

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

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


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

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

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

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

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

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

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

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

ответил Some Hardware Guy 9 FebruaryEurope/MoscowbMon, 09 Feb 2015 17:40:26 +0300000000pmMon, 09 Feb 2015 17:40:26 +030015 2015, 17:40:26
5

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

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

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

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

ответил user36129 9 FebruaryEurope/MoscowbMon, 09 Feb 2015 17:51:03 +0300000000pmMon, 09 Feb 2015 17:51:03 +030015 2015, 17:51:03
4

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

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

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

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

ответил tarabyte 10 FebruaryEurope/MoscowbTue, 10 Feb 2015 00:52:03 +0300000000amTue, 10 Feb 2015 00:52:03 +030015 2015, 00:52:03
3

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

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

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

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

ответил Scott Seidman 10 FebruaryEurope/MoscowbTue, 10 Feb 2015 01:32:22 +0300000000amTue, 10 Feb 2015 01:32:22 +030015 2015, 01:32:22
3

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

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

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

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

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

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

ответил ZSG 10 FebruaryEurope/MoscowbTue, 10 Feb 2015 08:05:21 +0300000000amTue, 10 Feb 2015 08:05:21 +030015 2015, 08:05:21
3

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

ответил Steve 14 ThuEurope/Moscow2017-12-14T23:11:07+03:00Europe/Moscow12bEurope/MoscowThu, 14 Dec 2017 23:11:07 +0300 2017, 23:11:07

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132