Уверенно фиксируйте все детали проекта в документации по дизайну печатных плат

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

ВВЕДЕНИЕ

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

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

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

СПЕЦИФИКАЦИЯ

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

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

Спецификация должна включать (но не ограничиваться):

- Функция (что предполагается делать подсистемой)

- Операционная среда (температура, влажность и т.д.)

- Интерфейсы с другими подсистемами

- Энергетический бюджет

- Доступные напряжения питания

- Механические ограничения размер/вес/форма

- Требования к ударным и вибрационным нагрузкам

- Тепловые (доступное охлаждение, ограничения на тепловое излучение и т.д.)

- ЭМИ излучаемые, проводимые и чувствительность

- Надежность.

Более того, список продолжается…

Обзор системы

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

Рассмотрение дизайна

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

Дизайн подсхемы

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

Название

Название должно описывать работу схемы.

Теория работы

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

Схема схемы

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

Рисунок 1: Схема может быть скопирована из инструмента захвата схем.

Расчеты Дизайна

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

Результаты Симуляции

Если были проведены симуляции подсхемы, результаты должны быть представлены. Также должна быть предоставлена подробная техническая характеристика результатов симуляции. При необходимости следует привести ссылку на пункт спецификации, который выполняется подсхемой, для обеспечения прослеживаемости.

Рисунок 2: Результаты симуляции должны быть включены.

Архитектура Интерфейса

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

Механические Особенности

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

Рисунок 3: Механические размеры и ключевые особенности подробно описаны на механических чертежах.

Анализ системы

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

ЗАКЛЮЧЕНИЕ

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