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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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