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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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