¿Cómo documenta sus decisiones de diseño de hardware?

Personalmente, sigo la ruta antigua: tengo un cuaderno de diseño donde escribo absolutamente todo sobre las decisiones de diseño que tomo. Especialmente opciones de componentes y valores, cálculos actuales, cálculos de fuente de alimentación, todo. También documento decisiones de software/firmware y notas sobre tiempo y uso de recursos.

Cada cuaderno tiene una página de contenido para hacer referencia a una parte específica del diseño (fuente de alimentación, etc.) y todas las páginas están numeradas.

He considerado pasarme a lo digital varias veces, pero es bueno tener mi cuaderno frente a mí mientras trabajo y encuentro que escribir fórmulas digitalmente es bastante incómodo. Es mucho más fácil escribir los cálculos a mano.

Cuando preparo una especificación o documentación formal para el diseño de una placa, generalmente vuelvo a consultar mi cuaderno para refrescar lo que hice (o escribo la documentación digital al mismo tiempo). Aunque parezca que estoy haciendo lo mismo dos veces, encuentro que mis cuadernos son básicamente cálculos y explicaciones para mí, mientras que la documentación es mucho menos detallada y mucho más formal y explicativa para los demás. Como tal, no suelo encontrar que estoy escribiendo lo mismo dos veces.

Puede volver atrás y actualizar las especificaciones de diseño con esta información. O tome la especificación y cree una especificación de nivel inferior donde describa con más detalle lo que va a hacer y por qué, idealmente antes de comenzar con los esquemas :). Luego actualice a medida que avanza y archive con los esquemas.

Respondiendo a las preguntas a continuación: Bueno, lo que generalmente hacemos es comenzar con los requisitos de marketing, luego tal vez una respuesta de ingeniería formal o simplemente una discusión informal. A esto le sigue un MRD (documento de requisitos de marketing), en palabras, usando nuestra plantilla. Eso incluye requisitos, análisis competitivo, tamaño del mercado, oportunidad, costo de desarrollo estimado, etc. Por lo general, esto lo escribe una persona de marketing (o alguien por encima de mi nivel de pago).

A esto le sigue el PRD (documento de requisitos del producto) escrito generalmente por ingeniería, también en una plantilla de Word. Esto describe con más detalles técnicos qué hará el producto, qué piezas se requieren y, en un nivel alto, cómo funcionará cada una de ellas. A menudo, incluiremos aquí el rendimiento objetivo, el precio, la potencia, el tamaño y otras métricas.

A esto le siguen especificaciones funcionales detalladas para cada una de las secciones. Parte del trabajo de diseño se realiza aquí mucho antes de incluirlo en el esquema. Por ejemplo, se calculará la potencia, se seleccionarán las piezas y se investigará mucho. Este es el lugar donde documentaríamos cualquier decisión de diseño no obvia.

Finalmente, llegaremos a los esquemas, que es la parte fácil en este punto porque gran parte del trabajo de diseño duro se realizó en la etapa de especificación. Donde debería hacerse en mi opinión :) Si algo cambia durante la etapa esquemática, por ejemplo, nos damos cuenta de que algo no funcionará o una persona de marketing viene corriendo por el pasillo diciendo que ahora debe ser rojo en lugar de azul, entonces regresará y actualizará las especificaciones.

Todas las especificaciones, PRD, MRD se mantienen en SVN con enlaces a los documentos en un wiki interno. Un cambio en las especificaciones dará como resultado una actualización de SVN y una notificación a las partes interesadas. Por supuesto, podría simplemente guardarlo manualmente en una carpeta compartida en algún lugar.

Ese es más o menos mi proceso, siento que querrás documentar cada pequeña decisión tomada sobre un diseño y definitivamente no hacemos eso. No digo que no debas, pude ver dónde sería útil. Supongo que normalmente documentamos el cómo y no el por qué todo el tiempo.

Ok, tal vez también debería haber abordado cada pregunta :)

Si está haciendo cálculos, ¿tal vez en Excel? O en papel y cree que los resultados y el método son importantes para la comprensión y el diseño de su circuito, entonces debe incluirlos en la sección correspondiente de la especificación de diseño. Incluso si eso significa tomar una foto de tu dibujo a mano :)

¿Por qué eligió este componente? Creo que la especificación funcional es un buen lugar para esto, no hay necesidad de volverse loco, solo una o dos líneas simples sobre cuáles fueron sus ventajas. Reservaría esto para componentes críticos, no creo que quieras describir por qué elegiste una resistencia pull-up, por ejemplo.

¿Por qué/cómo elegí estos parámetros particulares para este componente? Combina esto con lo anterior.

¿Qué hace esta parte del circuito? Esto sería parte de su especificación funcional, si el circuito es lo suficientemente importante como para justificar esta pregunta, debería tener su propia sección de la especificación.

¿Cuál es la disipación de potencia a través de este componente? Si está hablando de fuente de alimentación, coloque esto en la sección de alimentación, también me gusta anotar esto en los esquemas. Realmente, aunque todas mis partes provienen de una base de datos y el esquema está directamente vinculado a ellas, por lo que podemos ver fácilmente los parámetros, la hoja de datos, etc. Pero si solo tiene una copia impresa, es bueno saber algo de esto.

¿Cuál es el consumo total de energía de este circuito? Creo que esto pertenece a la sección de fuente de alimentación de su especificación.

¿Puedo reemplazar este componente por este otro? ¿Existen componentes equivalentes a este componente? etc. Esto creo que pertenece a su lista de materiales o cualquier proceso que utilice para la fabricación. Las piezas alternativas son para facilitar el abastecimiento. Una vez más, para nosotros, todo esto proviene de una base de datos de piezas.

Hago mucho diseño de giro rápido y tengo que decir: anotar el esquema es, con mucho, lo más conveniente. Es raro que alguno de mis diseños tenga más de 2 o 3 hojas A4, por lo que la cantidad de decisiones de diseño es limitada. Muchas decisiones de diseño son prácticamente automáticas; No necesito enumerar las razones de cada parte. Solo una o dos partes principales y tal vez algún filtro o detección de tamaño pasivo. El resto es inmediatamente obvio para cualquier ingeniero de diseño experimentado.

En cuanto a su última pregunta: las piezas alternativas generalmente no son una decisión de diseño sino una decisión de abastecimiento y, como tal, es parte de su flujo de trabajo de abastecimiento. En mi caso, las piezas alternativas se encuentran en las propiedades de mi pieza y se obtienen automáticamente si se agota el stock en la fuente o pieza principal.

Para diseños más grandes y para el diseño de sistemas, tiendo a usar Google Docs con una plantilla de documento de diseño.

En resumen; Personalmente, soy de la opinión de que un flujo de trabajo compacto valdrá la pena al final. Tener muchos archivos separados con información de diseño (diseño de sistema separado, documentos de decisiones de diseño, documentos de abastecimiento, todos separados de sus archivos básicos de esquema y diseño) genera mucho desorden (mental) y requiere cambiar de contexto cada vez que desea revisar un diseño. decisión. Tener todo en un solo lugar funciona bien. Si su esquema comienza a verse desordenado, esto no es un problema con este flujo de trabajo, sino que significa que probablemente debería compartimentar mejor su diseño, usar más hojas o usar hojas más grandes.

Para muchos de mis proyectos más pequeños, generalmente he estado colocando una etiqueta verde simple y un borde alrededor de los subcircuitos. Para proyectos más grandes, algunos programas de eCAD le permiten construir desde un diagrama de bloques hacia abajo, donde cada hoja describe un solo bloque. Hay un arte para descomponer cualquier problema y administrar las compensaciones (eso es ingeniería en mi humilde opinión). Donde claramente haya algún análisis para la elección de componentes como el filtrado analógico, anotaré la frecuencia de corte y el tipo de filtro (por ejemplo, filtro de paso bajo (f_c = 100 Hz))

Los bloques comunes con los que me encuentro una y otra vez incluyen:

• Administración de energía (reguladores de voltaje, protección contra polaridad inversa, diodos TVS, interruptor de encendido, tapas de derivación, etc.)
• MCU (microcontrolador, encabezado o almohadillas de programación, tapas de derivación de chips)
• Indicadores (p. ej., LED, cable EL, pantalla de 7 segundos, motor vibratorio)
• Detección de una característica en particular (por ejemplo, detección de corriente, detección táctil, GSR, actividad, detección ambiental, etc.)
• Comunicaciones de depuración (perla de ferrita, USB, I2C, UART, SPI, alguna forma de obtener información)
• Radio (todos los componentes de soporte para muchas radios)
• Video (todos los componentes y chips de soporte para una cámara)
• Almacenamiento externo (por ejemplo, flash externo, chip EEPROM para almacenar configuraciones, etc.)
• Cualquier otra característica exclusiva de su diseño.

Con estos subbloques claramente organizados y etiquetados, puedo consumir un esquema en menos de un par de minutos.

A menudo he usado Keynote (también puede optar por usar PowerPoint). Esto tiene la ventaja de permitir capturas de pantalla de software de simulación como GUI SPICE y similares.

Realmente clave para mí es la capacidad de colocar fragmentos de hojas de datos y marcarlos para que aparezcan las importancias relativas en mis decisiones de diseño. También puedo incluir fotos de las primeras placas de circuitos o placas de prueba, y enlaces a artículos que usé para tomar decisiones de diseño.

También encuentro que tiendo a querer hacer matemáticas y dibujos usando lápiz sobre papel. Así que tomo una foto con mi teléfono y la coloco en la nota clave sin volver a escribir. A veces, para ecuaciones cortas, puedo usar LaTeX y agregar eso.

También puedo incluir diagramas dibujados por software científico como octave.

Hoy en día, especialmente para tareas computacionalmente intensivas, puedo optar por hacer parte de este trabajo en cuadernos IPython, pero no lo he hecho específicamente para diseños de circuitos, solo para computación física.

Finalmente, Keynotes/Powerpoints son fáciles de embellecer para otros y exportarlos como pdf para distribuirlos a personas sin o menos técnicas.

Coloque notas de ingeniería en los esquemas y, si es necesario, cree más hojas. Siempre coloco notas de ingeniería en todos mis esquemas porque, en mi mundo, es posible que tenga que volver a visitar los diseños 1/2 horneados durante un período de tiempo y luego volver a ponerlos en un segundo plano mientras recojo otro diseño; Flujo de diseño muy fluido. Estas notas de EE nos ayudan a mí y a otros a volver a adoptar la intención del diseño con poco esfuerzo. También uso diferentes colores de texto/gráficos para indicar la importancia o el contexto. Ejemplo a continuación...

Mantengo un cuaderno de diseño y documento cuidadosamente las necesidades/deseos. Para los primeros prototipos, revisaré la selección de piezas y tomaré notas sobre todas las decisiones reales. Para los cambios posteriores, utilizo un proceso FMEA bastante formal, documentando qué necesidad no se está satisfaciendo para justificar un cambio, porque obviamente, si no hay una necesidad no satisfecha, ¡no hay necesidad de un cambio!

Si soy lo suficientemente riguroso con esto, puedo rastrear cada cambio de diseño (hardware, software, mecánica) hasta una necesidad.

Todas las versiones de todas las cosas se rastrean usando subversion.

Esto puede ser un componente sustancial de un archivo de historial de diseño, que es imprescindible para la FDA.