Estoy creando algunas diapositivas para mi clase sobre cómo debemos documentar el hardware que estamos desarrollando.
Me gustaría enumerar los documentos que debemos hacer al construir algún hardware. Me inspiré en la documentación del software UML, que trae muchos tipos de documentos para casi todas las situaciones.
Según mi experiencia e investigación, muchos proyectos solo tienen los esquemas, el diseño y la lista de materiales. Creo que también deberíamos agregar información sobre el motivo (requisitos) que nos llevan a elegir un microcontrolador y no el otro. También hay información sobre el diseño que simplemente no escribimos, como posición de componente especial que no se debe cambiar.
Dicho esto:
- ¿Cómo debemos documentar nuestro hardware?
- ¿Cuáles son los documentos importantes que desea tener si necesita hacer algunas mejoras / modificaciones en otro hardware que nunca ha visto?
- ¿Cómo organizar esta información de manera clara?
documentation
RMAAlmeida
fuente
fuente
Respuestas:
Estoy totalmente de acuerdo con tu tercer párrafo. Además de las cosas obvias como los esquemas, las listas de materiales, etc., están las cosas menos tangibles, como usted dice, por qué eligió un componente en particular y tan importante, por qué no eligió un componente quizás más obvio.
Ahora podría estar mostrando mi edad aquí, pero todavía me gusta usar un libro de registro con tapa dura para registrar mis procesos de pensamiento y decisiones de diseño, incluso las incorrectas. Si alguien en el futuro intenta reemplazar un componente con uno más 'adecuado' o mueve una pista en el PCB, mis notas podrían decirles que ya he estado allí y me quemé los dedos (¡tal vez literalmente!).
Siempre numero las páginas y dejo algunas páginas en la parte delantera como tabla de contenido. También puede documentar cosas tales como cálculos de disipación de energía, tolerancias, tiempos, etc. (este hábito proviene de mis días en la industria aeroespacial, donde era obligatorio mantener un libro de registro). Por supuesto, siempre puede poner esta información en un documento de WP, ¡pero me quedaré en papel!
Las descripciones de los circuitos también pueden ser apropiadas cuando se trata de circuitos inusuales (especialmente analógicos). Trataría estos como comentarios de software para documentar cualquier circuito no visible o funciones de componentes. Los esquemas, como el software, deberían 'auto documentarse' en la medida de lo posible, pero a veces esto no es suficiente.
Una alternativa más actualizada, especialmente en un entorno educativo, podría ser tener un sitio web del proyecto. Esto podría organizarse como una colección de blogs para cada disciplina: diseño de hardware, diseño de pcb, software, etc. La naturaleza del blog permitiría a los contribuyentes mostrar su flujo de pensamiento y documentar el progreso continuo del proyecto, mientras que otras páginas podrían ser más formales (progreso Diagramas de Gantt, resultados de pruebas, etc.). Incluso podría agregar actas de reuniones y listas de acciones. Los hipervínculos facilitan las referencias cruzadas y ahora tenemos MathJax, por lo que incluso las ecuaciones de diseño son fáciles de insertar.
fuente
En nuestra empresa se espera que escribamos documentos de descripción de diseño de hardware. Estos son bastante sencillos: explica al principio lo que se supone que debe hacer el circuito y luego entra en detalles en cada sección. Se supone que cada valor de componente está justificado de alguna manera: si tiene resistencias pullup o en serie "predeterminadas", deben mencionarse en una nota al principio (por ejemplo, "se utilizan pullups 10K y condensadores de derivación 0.1uF a menos que se especifique lo contrario") , de lo contrario, las opciones para los valores de los componentes deben explicarse. por ejemplo, "filtro RC de 4.7K y 0.1uF (tau = 0.47mseg) usado para limitar componentes de alta frecuencia" o "multiplexor NLAS4051 usado para baja fuga - este nodo del circuito es sensible".
fuente