2.6. - Fase de test de sistema
El test de sistema es la validación final del diseño. A partir de los requerimientos identificados al inicio del proceso de diseño se tiene que comprobar que cumplimos todos los requerimientos, o en todo caso, identificar aquellos requerimientos que no cumplimos.
Para un ámbito profesional, es habitual que esta fase de test de sistema esté supervisado por el cliente, de forma que incluso, sea el cliente quien haga la validación final.
Esta es la penúltima fase de diseño y debemos asegurarnos que toda la documentación de diseño queda convenientemente almacenada. Esta documentación será de vital importancia para el mantenimiento del diseño, y para la toma decisión de futuros proyectos.
2.7. - Fase de celebración
No hace falta demasiados detalles, que cada uno la describa para sí mismo...
jueves, 11 de abril de 2013
lunes, 8 de abril de 2013
Proceso de diseño de equipos electrónicos (7/8)
2.5. - Integración del sistema y desarrollo del software
El hardware fue validado en la fase anterior, en la fase de construcción del prototipo, y en esta fase, comprobamos que el software funciona correctamente con el hardware validado.
Programar y validar el software significa desarrollar y testear individualmente cada función del software.
Cuando una función esté validada, escribir otra función adicional y testear de nuevo. Se trata de ir incrementando la funcionalidad de forma progresiva, debugándola, hasta llegar a tener toda la funcionalidad implementada.
El hardware fue validado en la fase anterior, en la fase de construcción del prototipo, y en esta fase, comprobamos que el software funciona correctamente con el hardware validado.
Programar y validar el software significa desarrollar y testear individualmente cada función del software.
Cuando una función esté validada, escribir otra función adicional y testear de nuevo. Se trata de ir incrementando la funcionalidad de forma progresiva, debugándola, hasta llegar a tener toda la funcionalidad implementada.
viernes, 5 de abril de 2013
Proceso de diseño de equipos electrónicos (6/8)
2.4. - Fase de construcción y test del prototipo de hardware
Esta fase se describe en sí misma. En esta fase se tiene que constuir y testear el hardware, a partir de la documentación generada en la fase de diseño. Si se ha hecho bien el trabajo en fases previas, no deben haber sorpresas durante esta fase.
Para validar el diseño, una vez construido el prototipo, hay que simular las entradas y supervisar las salidas de forma que cuando se integre el software, estemos completamente seguros de que el hardware es correcto. Hay que evitar que cuando dispongamos del software no sepamos si los errores de funcionamiento son debidos al hardware.
En esta fase hay que utilizar la estrategia de dividir el test en partes, "divide y vencerás". No hay que pretender validar todo el hardware de una sola vez, hay que subdividir el problema de forma que vayamos validando bloques por separado.
Esta fase se describe en sí misma. En esta fase se tiene que constuir y testear el hardware, a partir de la documentación generada en la fase de diseño. Si se ha hecho bien el trabajo en fases previas, no deben haber sorpresas durante esta fase.
Para validar el diseño, una vez construido el prototipo, hay que simular las entradas y supervisar las salidas de forma que cuando se integre el software, estemos completamente seguros de que el hardware es correcto. Hay que evitar que cuando dispongamos del software no sepamos si los errores de funcionamiento son debidos al hardware.
En esta fase hay que utilizar la estrategia de dividir el test en partes, "divide y vencerás". No hay que pretender validar todo el hardware de una sola vez, hay que subdividir el problema de forma que vayamos validando bloques por separado.
jueves, 4 de abril de 2013
Proceso de diseño de equipos electrónicos (5/8)
2.3. - Fase de definición del Test
Cada uno de los bloques identificados en la fase de diseño tienen que ser testeados. En realidad hay dos tipos de tests:
- Test individual. Se comprueba una parte del diseño a bajo nivel.
- Test final, o test de sistema. Se comprueba todo el equipo en funcionamiento.
El objetivo de esta fase es describir los tests, y los resultados esperados, para cumplir con todos los requerimientos identificados en la fase de definición y diseño.
¿Qué pasa cuando no se comprueba que el equipo cumple con todos los requerimentos?, hay ejemplos dolorosos a lo largo de la historia, algunos de los más sonados:
- Apollo 13. El módulo lunar se quedó sin sistema de ventilación mientra orbitaba la luna.
Un extracto de la wikipedia dice:
La comisión de investigación de las causas del accidente determinó en su conclusión:
Si este tipo de errores ocurren en grandes proyecto aeroespaciales, con enormes esfuerzos de estanderización y gigantescos presupuestos, ¿qué no puede ocurrir en pequeñas organizaciones sin procesos de diseño definidos?...
Cada uno de los bloques identificados en la fase de diseño tienen que ser testeados. En realidad hay dos tipos de tests:
- Test individual. Se comprueba una parte del diseño a bajo nivel.
- Test final, o test de sistema. Se comprueba todo el equipo en funcionamiento.
El objetivo de esta fase es describir los tests, y los resultados esperados, para cumplir con todos los requerimientos identificados en la fase de definición y diseño.
¿Qué pasa cuando no se comprueba que el equipo cumple con todos los requerimentos?, hay ejemplos dolorosos a lo largo de la historia, algunos de los más sonados:
- Apollo 13. El módulo lunar se quedó sin sistema de ventilación mientra orbitaba la luna.
Un extracto de la wikipedia dice:
"The heater and protection thermostats were originally designed for the command module's 28-volt DC bus. The specifications for the heater and thermostat were later changed to allow a 65-volt ground supply, in order to pressurize the tanks more rapidly. Beechcraft, the tank subcontractor, did not upgrade the thermostat to handle the higher voltage. The temperature sensor could not read above the highest operational temperature of the heater, which was approximately 100 °F (38 °C). This was not normally a problem because the thermostat was designed to open at 80 °F(27 °C)."- Space Shuttle Challenger: transbordador espacial que explotó al despegar.
La comisión de investigación de las causas del accidente determinó en su conclusión:
"In view of the findings, the Commission concluded that the cause of the Challenger accident was the failure of the pressure seal in the aft field joint of the right Solid Rocket Booster. The failure was due to a faulty design unacceptably sensitive to a number of factors. These factors were the effects of temperature, physical dimensions, the character of materials, the effects of reusability, processing and the reaction of the joint to dynamic loading."
Si este tipo de errores ocurren en grandes proyecto aeroespaciales, con enormes esfuerzos de estanderización y gigantescos presupuestos, ¿qué no puede ocurrir en pequeñas organizaciones sin procesos de diseño definidos?...
martes, 2 de abril de 2013
Proceso de diseño de equipos electrónicos (4/8)
2.2. - Fase de Diseño
En el próximo post hablaré de la fase de definición del test.
En la fase de definición previa, describimos el sistema con grandes bloques funcionales. Solo hicimos algunos prototipos de aquellas partes más complejas o desconocidas (pruebas de concepto, o proofs of concept (PoC)) para comprobar la viabilidad del proyecto.
En esta fase se trata de entrar en el detalle. Cada uno de los bloques de hardware y software que se definieron previamente tienen que ser analizados y descritos.
Esta es la fase más importante del proyecto, se debe dedicar hasta el 50 % del tiempo total del proyecto. Si se hace correctamente, con el suficiente rigor, se conseguirá mantener controlado el proyecto y tendremos éxito en cuanto al plazo, coste, y cumpliendo los requerimientos de alcance del proyecto.
En cuanto al hardware, en esta fase, a partir de los grandes bloques descritos en la fase de definición, iremos bajando de nivel, desglosándolos en sub-bloques hasta llegar al nivel del esquemático. Utilizaremos herramientas de simulación (PSPICE, Webench, ...) cuando creamos que necesitemos validar el funcionamiento de un circuito, y mantendremos una exhaustiva documentación de todos las simulaciones. También mantendremos una documentación de los criterios que hemos seguido en la selección de los componentes. Es importante mantener un registro de los criterios de las decisiones de diseño, esa información nos puede ser muy útil para futuros proyectos.
En cuanto al software, en esta frase se trata de conseguir la definición en diagramas de bloque del flujo del programa. Hay que tomar decisiones sobre la gestión de las interrupciones, determinar las tareas críticas,...
Durante esta fase el desarrollo del software tiene que ir en paralelo con el desarrollo del hardware. Hay empresas en las que se crean dos grupos de trabajo muy diferenciados entre los desarrolladores del hardware y del firmware. Si no se aseguran canales fluidos de comunicación entre los dos equipos, los problemas de malos entendidos, falta de sincronización, ... no tardan en aparecer.
Esta sigue siendo una fase frustrante para el ingeniero inquieto que prefiere programar, o hackear el hardware, antes que documentar. Creo que hay que hacer una llamada a la profesional, o al gusto por hacer las cosas bien hechas, para evitar caer en la tentación de ir por libre. No se trata de hacer "algo" que funcione, se trata de hacer algo que funcione en el tiempo, coste establecidos, y con la calidad requerida, y para conseguir eso, hay que meditar y documentar previamente en las posibles opciones que se disponen. Desgraciadamente, esto es algo que a menudo no se comprende, y que tiene que ver mucho con la productividad de un departamento de diseño.
Como resultado de esta fase, se tiene que disponer de los diagramas de arquitectura y diagramas de flujo del software, y los esquemáticos, y listas de material, del hardware.En esta fase se trata de entrar en el detalle. Cada uno de los bloques de hardware y software que se definieron previamente tienen que ser analizados y descritos.
Esta es la fase más importante del proyecto, se debe dedicar hasta el 50 % del tiempo total del proyecto. Si se hace correctamente, con el suficiente rigor, se conseguirá mantener controlado el proyecto y tendremos éxito en cuanto al plazo, coste, y cumpliendo los requerimientos de alcance del proyecto.
En cuanto al hardware, en esta fase, a partir de los grandes bloques descritos en la fase de definición, iremos bajando de nivel, desglosándolos en sub-bloques hasta llegar al nivel del esquemático. Utilizaremos herramientas de simulación (PSPICE, Webench, ...) cuando creamos que necesitemos validar el funcionamiento de un circuito, y mantendremos una exhaustiva documentación de todos las simulaciones. También mantendremos una documentación de los criterios que hemos seguido en la selección de los componentes. Es importante mantener un registro de los criterios de las decisiones de diseño, esa información nos puede ser muy útil para futuros proyectos.
En cuanto al software, en esta frase se trata de conseguir la definición en diagramas de bloque del flujo del programa. Hay que tomar decisiones sobre la gestión de las interrupciones, determinar las tareas críticas,...
Durante esta fase el desarrollo del software tiene que ir en paralelo con el desarrollo del hardware. Hay empresas en las que se crean dos grupos de trabajo muy diferenciados entre los desarrolladores del hardware y del firmware. Si no se aseguran canales fluidos de comunicación entre los dos equipos, los problemas de malos entendidos, falta de sincronización, ... no tardan en aparecer.
Esta sigue siendo una fase frustrante para el ingeniero inquieto que prefiere programar, o hackear el hardware, antes que documentar. Creo que hay que hacer una llamada a la profesional, o al gusto por hacer las cosas bien hechas, para evitar caer en la tentación de ir por libre. No se trata de hacer "algo" que funcione, se trata de hacer algo que funcione en el tiempo, coste establecidos, y con la calidad requerida, y para conseguir eso, hay que meditar y documentar previamente en las posibles opciones que se disponen. Desgraciadamente, esto es algo que a menudo no se comprende, y que tiene que ver mucho con la productividad de un departamento de diseño.
En el próximo post hablaré de la fase de definición del test.
jueves, 28 de marzo de 2013
Proceso de diseño de equipos electrónicos (3/8)
2 - Proceso de diseño del proyecto
El proceso de diseño del proyecto se desglosa en varias subfases:
2.1. - Fase de definición
Es una fase teórica, se tata de hacer un estudio de viabilidad, no se empieza a diseñar electrónica aún.
Uno de los principales retos con los que debemos enfrentarnos durante el diseño electrónico, es intentar evitar diseñar demasiado pronto. La tentación nos empuja a ponernos a trastear lo antes posible, es divertido, y no hemos venido a la vida para sufrir... Pues bien, una de las principales causas de fracaso en un diseño es precisamente esa tendencia a empezar a tomar decisiones de diseño sin reflexionar antes sobre la mejor opción sobre la viabilidad funcional del diseño, la viabilidad económica del coste del desarrollo y del coste de producto final, ...
Sólo se bajará a algo de detalle si se ha detectado en el diseño alguna parte de la que nos estamos seguros que vaya a funcionar ya sea por su complejidad, o porque se soluciona con unos componentes que no conocemos. En ese caso, llevaremos a cabo simulaciones, prototipos sin demasiado detalle (a estos prototipos se les llama pruebas de concepto (proof of concept (PoC)).
Recomiendo para esta fase tranquilidad, una hoja en blanco, silencio y reflexión. Ya llegará el momento de trastear con electrónica, por ahora se trata sobretodo "solo" en pensar.
El objetivo de esta fase es escribir unas especificaciones técnicas que demuestren varias cosas:
- Hemos entendido las necesidades iniciales
- Hemos determinado cómo vamos a hacer el diseño con una descripción de grandes bloques y hemos demostramos que es una solución correcta.
- Hemos validado que las nuevas tecnologías, o las soluciones más difíciles, son correctas para este diseño a través de prototipos.
- Demostramos la viabilidad de la solución tanto a nivel funcional como a nivel económico.
De nuevo, dependiendo del ámbito en el que te muevas, se puede exigir una documentación muy exhaustiva. Puede resulta frustrante dedicar tanto tiempo a documentar y no bajar a la arena del diseño, pero es un paso necesario. Aún no he conocido a un ingeniero al que le guste documentar, pero insisto, es necesario pasar por aquí si no queremos eternizar nuestro diseño en un estúpido proceso de "prueba y error" que no suele acabar bien para nadie.
En los próximos posts seguiré hablando del proceso diseño.
El proceso de diseño del proyecto se desglosa en varias subfases:
2.1. - Fase de definición
Es una fase teórica, se tata de hacer un estudio de viabilidad, no se empieza a diseñar electrónica aún.
Uno de los principales retos con los que debemos enfrentarnos durante el diseño electrónico, es intentar evitar diseñar demasiado pronto. La tentación nos empuja a ponernos a trastear lo antes posible, es divertido, y no hemos venido a la vida para sufrir... Pues bien, una de las principales causas de fracaso en un diseño es precisamente esa tendencia a empezar a tomar decisiones de diseño sin reflexionar antes sobre la mejor opción sobre la viabilidad funcional del diseño, la viabilidad económica del coste del desarrollo y del coste de producto final, ...
Sólo se bajará a algo de detalle si se ha detectado en el diseño alguna parte de la que nos estamos seguros que vaya a funcionar ya sea por su complejidad, o porque se soluciona con unos componentes que no conocemos. En ese caso, llevaremos a cabo simulaciones, prototipos sin demasiado detalle (a estos prototipos se les llama pruebas de concepto (proof of concept (PoC)).
Recomiendo para esta fase tranquilidad, una hoja en blanco, silencio y reflexión. Ya llegará el momento de trastear con electrónica, por ahora se trata sobretodo "solo" en pensar.
El objetivo de esta fase es escribir unas especificaciones técnicas que demuestren varias cosas:
- Hemos entendido las necesidades iniciales
- Hemos determinado cómo vamos a hacer el diseño con una descripción de grandes bloques y hemos demostramos que es una solución correcta.
- Hemos validado que las nuevas tecnologías, o las soluciones más difíciles, son correctas para este diseño a través de prototipos.
- Demostramos la viabilidad de la solución tanto a nivel funcional como a nivel económico.
De nuevo, dependiendo del ámbito en el que te muevas, se puede exigir una documentación muy exhaustiva. Puede resulta frustrante dedicar tanto tiempo a documentar y no bajar a la arena del diseño, pero es un paso necesario. Aún no he conocido a un ingeniero al que le guste documentar, pero insisto, es necesario pasar por aquí si no queremos eternizar nuestro diseño en un estúpido proceso de "prueba y error" que no suele acabar bien para nadie.
En los próximos posts seguiré hablando del proceso diseño.
lunes, 25 de marzo de 2013
RFduino
RFduino, un microcontrolador que incorpora el soporte wireless (Bluetooth 4.0), del tamaño de una uña. Y además, se puede programar con el IDE de Arduino:
Suscribirse a:
Entradas (Atom)