¿Cómo estructuran grandes proyectos integrados?

Question

Antecedentes:

Junior I + D, ingeniero en electrónica (sólo EE en la empresa) - el hardware y la programación no es el problema. Mi mayor problema es conseguir una adecuada visión de conjunto del proyecto, y por dónde empezar.

Hasta ahora sólo he hecho menor proyectos de software (sub 500 líneas de código), pero me puedo imaginar a mí mismo haciendo proyectos más grandes, sin perder la visión general de la funcionalidad o la falta de funcionalidad.

Cómo hacer el mejor estructura / ¿qué herramientas se utilizan para estructurar grandes sistemas de software embebido?

Lo que estoy haciendo actualmente:

Me suelen empezar, con el esbozo de la funcionalidad del proyecto. Podría ser de una a muchas capas de diagramas de flujo o relacionados con los diagramas de bloque, diagramas, etc.) y hacer un poco de investigación de los componentes/chips. Entonces me salta directamente a la codificación (fail fast supongo) haciendo referencia a las hojas de datos / Internet, Codificación de una funcionalidad en el tiempo y hacer las pruebas con datos ficticios, o una prueba similar. Podría ser la escritura de datos en el MEM chip, y entonces si que funciona, a continuación, podría ser un SPI conductor entre el chip y la memoria del chip.

¿Qué respuesta que estoy buscando:

De nada realmente. Voy a ordenar lo que me parece sensato. Podría ser un libro, un artículo, una experiencia personal, recomendaciones, etc.

Estoy muy interesado en saber cómo los adultos mayores frente a este.

---

Editar

En primer lugar, gracias por compartir sus años de experiencia! Todas las respuestas son muy apreciadas. Mi opinión de esto es;

• Crear un claro y preciso en el documento de especificación.
• Crear un documento de diseño de software. (Algo que ahora he de añadir) Diseño de plantillas doc
• Pensar en los módulos de cómo cada vez redundante que parezca. (Tengo algo para centrarse más en)
• Seguir un estándar de codificación para la estructuración de encabezado/archivos de origen. (Nunca hizo esto) Barr Grupo C estándar
• Centrarse en la creación, el bajo nivel de las implementaciones de primera. (Comunicación etc.)
• Implementar patrones de diseño siempre que sea posible/sensible. Patrones de diseño
• Configurar algo para control de revisión (Github, etc. - nunca utilizado tanto)
• La investigación de integración continua / continua implementación (Algo nuevo que me tropecé) CI & CD fundamentos

Answer 1

Hay varios aspectos que influyen en el grado de detalle de la estructuración de un proyecto de necesidades. Para mí uno de los factores principales es la de si yo soy el único de codificación (lo que parece ser el caso para usted escribe tú eres la única EE) o si hay otras personas involucradas. Luego está la cuestión de lo "grande" en realidad significa. Por lo general, se dividen el proceso de diseño en los siguientes pasos:

La definición de los requisitos Si usted consigue la correcta especificación de software para trabajar con una gran cantidad de planificación ya está hecho. Si usted acaba de conseguir los requisitos vagos, la primera cosa que usted tiene que hacer es ordenar a lo que el cliente realmente quiere (a veces no saben realmente en el primer lugar). Sé que es tentador saltar a la derecha en la codificación, pero la que trae el riesgo de perder una característica importante que podría no fue evidente en el primer lugar y no puede ser fácilmente aplastado en su código sólo en algún lugar en el medio de desarrollo.

Los límites del sistema y la facilidad de mantenimiento En sistemas integrados, que a menudo tienen algunas de las interfaces del sistema, algunos hacia el exterior (operador), pero también en el interior. Definir estas bien y tratar de mantener las dependencias tan bajo como sea posible, esto simplificará continua de ingeniería y mantenimiento. También comentar/código de documento donde se necesita, usted nunca sabe quién más tendrá que trabajar con él, (s)él estará encantado de no tener que cavar a pesar de una docena de capas de código antes de saber realmente qué función realiza.

Definir verificable tareas Especialmente si otros desarrolladores están trabajando en la misma base de código es inevitable definir claramente las tareas (funciones) y las interfaces entre ellos. Siempre que sea posible, las características individuales debe ser probado y/o verificado independiente de los demás, que es donde tiene los interfaces bien definidas, de modo que usted puede definir los casos de prueba.

Una característica después de la otra Gente como el progreso, por lo que si usted tiene una variedad de tareas que suelen trabajar en lo que promete la mayoría de los avances. Generalmente trato de terminar una tarea y llevarla a un verificados y probados estado antes de empezar con la siguiente. Esto permite que el código para ser probado por los demás y no terminan olvidando de algo.

Revisión De Control De Durante la vida de un proyecto a veces es necesario versiones anteriores, tal vez para identificar un error introducido con alguna nueva versión o simplemente para construir un dispositivo que se comporta exactamente de la misma manera como usted enviado hace 3 años. Asegúrese de tener claro a construir las revisiones y las etiquetas en el código. Git es definitivamente tu amigo aquí.

Answer 2

Humpawumpa escribió una gran respuesta! Solo quiero complementar algunos de sus puntos, pero ya que este es demasiado largo para un comentario, voy a escribir una de respuestas separada.

Yo estaba una vez en el OP de la posición no es la única EE, pero la única EE que había hecho MCU de desarrollo en una empresa pequeña.

No puedo enfatizar la importancia de la modularidad suficiente, incluso si eres el único desarrollador. Es la única manera de mantenerse sano a medida que el proyecto crece. Usted necesita ser muy estrictos acerca de la escritura de módulos que se encargan de sólo un concepto funcional de cada uno, y mantener sus interfaces externas al mínimo posible. De alto nivel de los módulos que corresponden a los requisitos funcionales, mientras que las de bajo nivel de los módulos de tener vínculos estrechos con los recursos de hardware (es decir, los controladores de dispositivo).

Me pasé un montón de tiempo, manteniendo un detallado diagrama de flujo de datos¹, que mostró exactamente cómo los distintos módulos de la información compartida. Algunas funciones se tienen requisitos muy diferentes en términos de rendimiento en tiempo real, asegúrese de que usted sabe cómo el intercambio de información que afecta. El diagrama que se había límites dibujados a través de ella que se separaron de la no-código de interrupción de los diversos interrumpir impulsado por dominios.

---

¹ Muy diferente de la de un diagrama de flujo, que se centra en el control de flujo.

Answer 3

Para cualquier gran proyecto, mi plan es como si hubiera varios desarrolladores involucrados , incluso si tengo la intención de hacer todo yo mismo.

Las razones son simples:

1 Complejidad. Un gran proyecto siempre tiene complejidades involucradas. Después de haber planeado el proyecto como si allí fueron varios los equipos que participan significa que la complejidad ha sido considerado y documentada. El número de veces que he visto a grandes proyectos a ejecutar en problemas es alta y generalmente porque algo se deslizó a través de las grietas'. No olvides que la mecánica de la asamblea también debe ser considerado y no simplemente por el tamaño de la caja - no habrá necesidad de disipadores de calor? Debe el cuadro estar conectado a tierra para la seguridad? Hay muchas preguntas en esta categoría solo.

2 Requisitos. Suponiendo que varias personas están involucradas significa que el nivel superior de los requisitos (que a menudo me reto, ya que pueden traer una complejidad innecesaria y costo) debe dividirse en varios de menor tamaño requerido y alcanzables tareas (que podría ser alimentados a un otro equipo en una organización grande) en lugar de sólo mirar a una sola nota.

3 Particiones. Hay dos tipos principales de partición; la funcionalidad del hardware y software / hardware. El primer tipo es determinar qué separados (pero la comunicación) bloques funcionales deben estar presentes. El segundo es un trade-off de la más sencilla (a veces) de hardware y software, pero tenga en mente que simplemente mover más cosas a software no necesariamente solucionar un problema de hardware. Se mueve más en el software, en realidad puede aumentar considerablemente el hardware de la complejidad en algunas circunstancias (más potencia de procesamiento, más interfaces complejas y más).

4 Interfaces. El proceso de particionado ayudará a definir las interfaces internas; interfaces externas son generalmente parte de los requisitos generales (aunque no siempre). Hay muchas maneras para diferentes partes de un sistema de co-operar que puede ser un complejo protocolo de comunicaciones o simplemente la buena / mala señalización.

5 Verificación. Esta es una mezcla de bajo nivel de la prueba (para el hardware y los controladores) y a nivel de sistema. Después de haber hecho el proyecto en bien definidos los bloques de permisos de verificación robusta (que puede ser por medio de un análisis o examen real, y es por lo general una mezcla de los dos; las actualizaciones de los diseños pueden usar la similitud de argumentos).

6 Normas. Yo uso la codificación y normas de dibujo como si fuera un equipo más grande. Yo uso Barr del grupo de estándares de codificación , ya que no son demasiado onerosos pero, ¿a prevenir muchas clases de error está en el código. Para PCB de salida de la documentación que yo siga IPC-D-326 (que se llama IPC-D-325) como que es un método probado de comunicar mi intención de PCB fabricantes y ensambladores. Esto puede parecer extraño, pero tener la disciplina para seguir una serie de normas que significa que la calidad es constante.

7 control de la Versión. Yo uso la versión de control para todas las partes del proyecto (sistema, hardware, software. mecánico, requisitos de prueba - todo). Las herramientas de CAD I apoyar el uso de tales versiones de como hacer todo el software de FPGA y herramientas de construcción.

He trabajado en muchos proyectos integrados (como lo han hecho muchos de la experiencia popular por aquí) y el tamaño de los equipos han variado desde el 1 (el mismo) decenas (o cientos en un determinado conjunto de proyectos) difundir a través de múltiples disciplinas y, a veces, otros geográficamente los sitios remotos. Utilizando el mismo primordial de enfoque (que se sabe que funciona) significa que puede recoger una tarea determinada en un relativo aislamiento y completa y a fondo de la prueba como un stand-alone parte de un proyecto más amplio. Esto también significa que se pueden sub algunas cosas de ocasión, si es necesario.

Hacer todas estas cosas le añade un poco de tiempo, pero es en última instancia una ruta más rápida para los complejos sistemas embebidos.

Answer 4

Las otras respuestas dar muchos consejos. Aquí están las dos que he encontrado el más importante en mi desarrollo integrado de la carrera:

1. Realizar como parte del código en separar, bien definidos los módulos como sea posible.
2. Hacer que los módulos automáticamente comprobable en el PC.

Eso es lo que usted necesita para hacer "integración continua" estilo de desarrollo en sistemas embebidos. Siempre habrá una cierta cantidad de código que es demasiado estrechamente relacionado con el hardware para la automatización de pruebas, pero tratar de minimizarlo. Usted puede conseguir muy lejos usando datos simulados o tomas de datos de hardware real, que luego se utilizará en el sistema de prueba.

Answer 5

Para añadir a las respuestas...

Yo siempre empiezo desde abajo hacia arriba. A partir de su diseño de hardware, usted sabe lo que su I/O es. Comience por la construcción de los módulos de los controladores que encapsulan que de e/S, por lo que su alto nivel de código no tiene que saber mucho sobre el bajo nivel de las cosas.

Cuando usted está construyendo el bajo nivel de interfaces, por supuesto, usted necesita un arnés de prueba. Si el diseño de este para conectar a la PC desde el principio (tal vez con un puerto RS-232, quizás USB, tal vez telnet a través de Ethernet), entonces usted puede mantener este instrumento de prueba de la interfaz en lugar de como construir tu aplicación. Puede seguir añadiendo más arnés de prueba ganchos como la aplicación toma forma, y que te permitirán regresión de la prueba de su código, ya que como bien.