Maximizando el Rendimiento en un Sistema de Prueba Automatizado

Bienvenido a la Guía para Desarrolladores que Diseñan los Sistemas de Prueba de la Nueva Generación. Esta guía es una colección de documentos diseñados para ayudarle a desarrollar sistemas de prueba que le ayudarán a bajar costos, incrementar el rendimiento de prueba, y que pueden actualizarse con requerimientos futuros. Este documento proporciona estrategias para maximizar el rendimiento del sistema.

Introducción a Mejoras del Rendimiento del Sistema

"¿Cómo maximizo el rendimiento en mi sistema automatizado de prueba?" resulta una pregunta común hecha por muchos ingenieros y científicos. Por años, ingenieros han empleado numerosas estrategias para extraer mayor velocidad de sus sistemas tanto en laboratorios como en el piso de producción. Estas técnicas de optimización han incluido con frecuencia el uso de fuerza bruta en procedimientos como son: cortar el número de pruebas y comprar instrumentos que resultan redundantes. Este documento describe cuatro estrategias para maximizar el procesamiento sin realizar muchos sacrificios. Estas estrategias incluyen:

Estrategia 1: Elija el Bus con Mayor Rendimiento para su Aplicación

En apariencia, puede parecer directa la elección del bus en base al ancho de banda solamente. El ancho de banda teórico, puede ser un indicativo del desempeño, sin embargo,  no es tan sencillo. En realidad, existen cuatro factores principales que afectan el desempeño del bus – ancho de banda, latencia, implementación y aplicación. Y debido a que la mayoría de los buses para prueba en industrias se basan en buses PC, siguen la tendencia PC de que los buses del sistema como PCI y PCI Express se desempeñan mejor que los buses de comunicación como USB y LAN.

Figura 1. Ancho de banda versus Latencia de Pruebas de Flujo y Buses de Medida

Muchas comparaciones del desempeño del bus se enfocan solamente en el ancho de banda del bus e ignoran los otros componentes del hardware y software que influyen en el actual desempeño del bus. El ancho de banda es la tasa de transferencia de los datos. Esto, usualmente se mide en millones de bytes por segundo (MB/s). La latencia es el tiempo de transferencia. Ésta, usualmente se mide en microsegundos (µs). Por ejemplo, en las transferencias Ethernet, se dividen grandes bloques de datos en pequeños segmentos y se envían en múltiples paquetes. La latencia es la cantidad de tiempo que toma transferir uno de estos paquetes. La Figura 1 compara el ancho de banda teórico versus las latencias de las pruebas de flujo y buses de medida.

La implementación del software, firmware y hardware del bus, afectan su desempeño. No todos los instrumentos son creados iguales. Una PC implementada con un procesador más rápido y más RAM desempeña mejor que una con un procesador más lento y menos RAM. Lo mismo aplica para instrumentos. Los cambios en la implementación hechos por el diseñador del sistema, ya sea trabajando con un instrumento virtual definido por el usuario o un instrumento tradicional definido por un vendedor, tiene un impacto en el desempeño del instrumento. Uno de los beneficios principales de los instrumentos virtuales es que el usuario final, así como el diseñador de instrumentos, deciden los cambios de implementación óptimos.

El factor final que más afecta el desempeño del bus es la aplicación o cómo es que el instrumento está siendo utilizado. El hardware de E/S y firmware del instrumento, la combinación CPU/RAM, el software de aplicación, y velocidad de medida, afectan el desempeño del bus. Cambiar alguno de estos componentes puede cambiar el desempeño del bus, así que el cambiar de un bus a otro afecta el desempeño por completo del sistema. En algunas aplicaciones, la medida del subsistema representa un cuello de botella, y en otras, el cuello de botella es el subsistema del procesador. La comprensión de cuál subsistema está siendo el cuello de botella, proporciona un camino para mejorar el desempeño. El punto clave que permanece para que un bus en particular continúe teniendo un alto desempeño o sea inclusive utilizable, es que debe exceder los requerimientos de la aplicación.

Estos factores impactan si el bus de instrumento excede el desempeño requerido. Utilice los estándares para comparar el desempeño actual entre instrumentos potenciales. Para más detalles acerca de cómo elegir un bus, vea el documento fuente ¿Qué Hace un Bus de Alto Desempeño?

Estrategia 2: Seleccione el Software que Tome Mayor Ventaja de la Tecnología más Actual de Procesadores

Los procesadores de múltiples núcleos son la última innovación en la industria de las PCs. Los primeros procesadores de múltiples núcleos contienen dos núcleos, o motores computacionales, localizados físicamente en un procesador. Los procesadores con dos o más núcleos pueden ejecutar más de dos tareas simultáneamente. Los procesadores de núcleo dual pueden ejecutar simultáneamente dos tareas computacionales. Ésto, representa una ventaja en ambientes de tareas múltiples, como Windows XP, en donde usted puede ejecutar múltiples aplicaciones. Dos aplicaciones – LabVIEW de National Instruments y Microsoft Excel, por ejemplo – pueden tener acceso, cada uno, al núcleo del procesador por separado, por tanto, mejorando el desempeño para aplicaciones como lo es el acceso de datos.

La otra ventaja principal de desempeño es otorgada a las aplicaciones multihilo. Esto otorga a la aplicación la habilidad para separar sus tareas en hilos individuales. Un procesador de núcleo dual puede ejecutar simultáneamente dos de estos hilos. Las PC de núcleo dual demuestran mejoras significativas en su desempeño, especialmente en aplicaciones multihilo. Comparativos en LabVIEW 8.20 de NI demuestran una mejora en el desempeño para aplicaciones multihilo de hasta un 25 por ciento entre el controlador de núcleo dual PXI-8105 de National Instruments y el controlador de un solo núcleo PXI-8196 (procesador Intel Pentium M 760 de 2.0 GHz), los cuales cuentan con un procesador con tasas de reloj equivalentes. Esto es el resultado de numerosas mejoras en el procesador y configuraciones de chip entre estos dos generaciones de arquitectura Intel. Usted puede observar la mejora en desempeño a partir del hecho de que el procesador PXI-8105 es de núcleo dual en los estándares de aplicación multihilo, lo cual demuestra una mejora de hasta 100 por ciento comparada con el controlador PXI-8196.

Multihilo puede mejorar significativamente el desempeño del sistema de prueba. Durante las pruebas de una unidad (UUT), algunas de las acciones son independientes de su funcionalidad y uso de recursos. Por ejemplo, al probar un dispositivo, puede necesitar inicializar varios instrumentos. La inicialización de diferentes instrumentos es totalmente independiente. Por tanto, puede usted romper estas tareas en múltiples ramas para mejorar el desempeño. Para tomar una completa ventaja de esta capacidad, debe elegir un software que soporte multihilo al nivel del dispositivo de comunicación y aplicación para probar a un nivel ejecutivo. Por ejemplo, usted requiere elegir dispositivos de hardware que incluyan dispositivos de software ramificados. Por esta razón, todos los dispositivos de hardware NI son lanzados al mercado con dispositivos de software ramificados.

Además, usted debe considerar el nivel de conocimiento requerido para tomar ventaja de estos procesadores de múltiples núcleos. Por ejemplo, los lenguajes de programación basados en texto incluyen bibliotecas multihilo incluidas para crear y manejar hilos. Sin embargo, en los lenguajes basados en texto donde el código típicamente se ejecuta de manera secuencial, resulta difícil visualizar cómo es que varias secciones del código son ejecutadas en paralelo. Debido a que la síntaxis del lenguaje es secuencial, el código básicamente se ejecuta línea por línea. Y debido a que las ramas dentro de un mismo programa usualmente comparten datos, la comunicación entre ramas para coordinar datos y recursos resulta tan crítica que debe implementarla cautelosamente para evitar un comportamiento incorrecto en la ejecución en paralelo. Debe escribir un código extra para manejar estas ramificaciones. Por tanto, el proceso de convertir una aplicación de una rama a una de varias ramificaciones puede consumir mucho tiempo y generar errores.

El lenguaje de programación basado en texto debe incorporar funciones de sincronización especiales al compartir recursos como la memoria. Si usted no implementa a su aplicación, las ramificaciones de forma apropiada, puede experimentar un comportamiento inesperado. Pueden ocurrir conflictos cuando varias ramas pidan compartir recursos simultáneamente o compartir espacio para datos en la memoria. Herramientas actuales, como los depuradores de ramificaciones, ayudan mucho, pero en la mayoría de los casos, debe mantener control de los códigos fuente para prevenir conflictos. Adicionalmente, debe adaptar su código con frecuencia para poder acomodar en paralelo su programación.

En cambio, las herramientas de programación gráfica como LabVIEW pueden representar fácilmente procesos en paralelo y están inherentemente en multihilo. Por ejemplo, dos iteraciones ejecutándose de forma independiente, se ejecutan automáticamente en hilos separados.

[+] Ampliar Imagen

Figura 2. La naturaleza paralela de la programación gráfica implementa automáticamente multihilo en núcleos de procesamiento separados.

En computadoras con procesadores de núcleo dual, los VIs ramificados de LabVIEW pueden manejar un incremento en el desempeño sin intervención alguna de su parte. Los múltiples hilos se programan para ejecutarse en procesadores separados sin instrucción externa. Para mayores detalles, vea el documento   Usando LabVIEW para crear Aplicaciones Multihilo para Maximizar el Desempeño y Confiabilidad.

Estrategia 3: Utilice Sincronización de Hardware

Prácticamente todos los sistemas de prueba automatizados requieren que ingenieros sincronicen dos o más instrumentos o interruptores. Por ejemplo, en una aplicación de prueba para células de combustible, un ingeniero debe programar un multímetro digital para realizar un escaneo a través de cientos de células individuales con el uso de un interruptor. Existen dos tipos de sincronización para elegir: temporizado por software y temporizado por hardware. La sincronización de un software temporizado emplea disparos generados por una llamada de software, y el hardware emplea disparos generados por señales conectadas a las líneas de disparo del hardware. Con la sincronización del software, hay suficiente dependencia y sumersión del software debido a que el software temporizado requiere de intervención del software para avanzar el disparo para cada lectura. El tiempo de estos escaneos está sujeto al desempeño del sistema de software debido a que el software comparte recursos con todas las otras aplicaciones que requieren tiempo del procesador.

El procesamiento es maximizado al implementar la sincronización del hardware temporizado el cual remueve la dependencia del procesador. La sincronización del hardware toma ventaja de los disparos de ambos instrumentos intentando comunicarse. Con el uso del ejemplo del interruptor DMM visto anteriormente, en vez de agregar retraso al software para permitir el tiempo de fijación del interruptor, el instrumento e interruptor interactúan enviando disparos entre ellos al estar listos o completos. El instrumento envía una señal de disparo cuando la lectura está completa, y el interruptor envía un disparo una vez que se ha fijado y está listo para la siguiente medida. Todas las interacciones de disparo están controladas por el hardware, lo cual minimiza el tiempo perdido entre medidas, garantizando el máximo procesamiento. La sincronización del hardware entre el interruptor e instrumento es completamente independiente del ambiente del software y no está afectado por el software.

Figura 3. Esquema de Sincronización del Hardware para un Multímetro e Interruptor

En la Figura 3 se muestra un ejemplo de sincronización de hardware. En este ejemplo, el PXI-4070 FlexDMM de NI se comunica con el interruptor PXI-2530, el cual es un multiplexor de muchos canales. Después de cerrar el primer canal, el interruptor de disparo se comunica con el DMM para que tome una medida. Cuando el DMM completa la medida, el disparo se comunica con el interruptor para que se mueva hacia el siguiente canal, y el ciclo se repite sin intervención del software. Debido a su determinismo, la actividad del software adicional (como el procesamiento adicional de datos) no afecta los resultados de la prueba de movimiento del hardware como lo hace cuando el escaneo del software está siendo utilizado.

La mejora en el tiempo de ejecución del hardware puede observarse en la Tabla 1. Estos, son resultados estándares para 1,000 escaneos del interruptor DMM los cuales utilizan un interruptor PXI-2501 FET de NI y un PXI-4070 FlexDMM. El uso del movimiento del hardware incrementa el procesamiento en más de 46 por ciento. También note que en el caso del movimiento del hardware tiende más a procesar tareas de software, lo cual alenta mucho la ejecución del escaneo del software.

 

	Ejecución Estándar	Con Procesamiento Adicional	% de Cambio
Escaneo de Software	3021 ms	3840 ms	27
Movimiento de Hardware	1640 ms	1655 ms	0.9
% de Incremento de Procesamiento Empleando el Movimiento de Hardware	46	57

Tabla 1. Comparación de Tiempo de Ejecución para 1,000 Escaneos del Interruptor DMM

El determinismo y procesamiento del sistema es maximizado con la sincronización del hardware. Adicionalmente, si se emplea la instrumentación PXI, entonces todas las señales de disparo son pasadas sobre el plano posterior de la sincronización PXI, eliminando la necesidad de cables externos y simplificación de configuración. Para más detalles, vea el documento Optimice el Procesamiento de la Prueba de Manufactura Usando la Sincronización del Hardware de Medida.

Estrategia 4: Diseñe una Arquitectura de Sistema que Soporte Pruebas en Paralelo y Comparta Recursos

Puede usted haber explorado con anterioridad las formas de mejorar el procesamiento del sistema de prueba a través de pruebas en paralelo. Sin embargo, las herramientas de administración de software comercial más actuales aminoran los costos del sistema de prueba. En general, las pruebas en paralelo involucran probar productos en paralelo o subcomponentes de forma simultánea. Una estación de prueba en paralelo comparte un conjunto de equipos de prueba a través de múltiples interruptores de prueba, pero, en algunos casos, puede tener un conjunto de hardware por separado para cada UUT. La mayoría de los sistemas de prueba no paralelos prueban solo un producto o subcomponente a la vez, dejando inactivas las pruebas de hardware costosas más de 50 por ciento del tiempo de prueba. Por tanto, con las pruebas en paralelo, usted puede incrementar el procesamiento de las pruebas de manufactura sin gastar mucho dinero en duplicar o descartar sistemas de prueba adicionales. Las siguientes secciones presentan maneras en las cuales las pruebas en paralelo pueden reducir el costo de prueba y describe varias formas en las cuales se pueden implementar las pruebas en paralelo en sus sistemas de prueba.

Eligiendo una Arquitectura para la Prueba en Paralelo
Mientras que usted puede implementar las pruebas en paralelo en la mayoría de los sistemas de prueba, la arquitectura del sistema de prueba modular entrega mejores resultados al emplear un ambiente de pruebas en paralelo. El software de administración de pruebas, como NI TestStand, y componentes modulares hardware PXI ofrecen muchas características para obtener el mayor desempeño fuera del sistema de prueba en paralelo. Sin embargo, usted puede implementar pruebas en paralelo usando mucho de su hardware de prueba sin invertir más en hardware. Una vez seleccionada su arquitectura de prueba, el siguiente paso consiste en seleccionar el mejor modelo de proceso basado en el mejor comportamiento de su prueba UUT.

Módulos Comunes de Procesos en Paralelo
Al probar el ensamble o funcionalidad más apropiado para el UUT, existe una gran variedad de tareas que desempeñar en cualquier sistema de prueba. Estas tareas incluyen una mezcla del modelo o familias de prueba específicas así como muchos procedimientos que no tienen nada que ver con las pruebas que realmente se le hacen al UUT. Un modelo de proceso separa las tareas del sistema de las pruebas específicas al UUT para reducir significativamente los esfuerzos de desarrollo y aumentan el uso del mismo código. Algunas de las tareas que pueden manejar el modelo de proceso consiste en rastrear el número de identificación del UUT, inicialización de instrumentos, iniciar ejecuciones de prueba, coleccionar resultados de pruebas, y contar con el acceso a los datos de los resultados en las pruebas o bases de datos. NI TestStand proporciona dos modelos de proceso, el modelo de proceso en paralelo y el modelo de proceso por lotes, para facilitar el flujo de la prueba en general en base a los requerimientos de su prueba UUT.

Puede utilizar el modelo de proceso en paralelo para probar interruptores de prueba independientes. Con este modelo, puede iniciar y detener las pruebas en cualquier UUT y en cualquier momento. Por ejemplo, puede usted tener cinco interruptores de prueba para desempeñar pruebas en los tableros de radio. Con el uso del modelo de proceso en paralelo, usted puede cargar un tablero nuevo en un interruptor abierto mientras que otros interruptores prueban otros tableros. La Figura 4 ilustra cómo se ejecuta el proceso en paralelo.

Figura 4. Diagrama de Flujo del Modelo de Proceso en Paralelo

Alternativamente, usted puede utilizar un modelo de proceso por lotes para controlar un conjunto de interruptores de prueba que prueben múltiples UUT como grupo. Por ejemplo, usted puede tener un conjunto de tableros con circuitos adjuntos a un cargador común. El modelo por lotes asegura un inicio y fin a las pruebas de todos los tableros al mismo tiempo. El modelo por lotes proporciona características de sincronización por lotes. Por ejemplo, puede especificar que el paso se ejecuta una vez por lote si es que un paso en particular aplica al lote completo. Con un modelo de proceso por lotes, también puede especificar que ciertos pasos o grupos no pueden ejecutar más de un UUT a la vez o que ciertos pasos deben ejecutarse en todos los UUTs simultáneamente.

Instrumentos Compartidos
Si usted está intentando incrementar el desempeño de su sistema de prueba mientras disminuye costos, resulta una solución inconveniente proporcionar a cada interruptor un conjunto de instrumentos a cada uno. La implementación de un sistema de prueba en paralelo con frecuencia no requiere de inversión adicional al hardware. Con las pruebas en paralelo, usted puede compartir instrumentación existente en su sistema de prueba, entre múltiples interruptores de prueba. Aminorar el tiempo de hibernación durante un ciclo de prueba al UUT proporciona un desempeño sustancial sin que el hardware incurra en costos adicionales. En muchos casos, puede agregar otros instrumentos que no sean costosos para optimizar de mejor manera el desempeño de todo el sistema mientras comparte el hardware más costoso entre los interruptores de prueba.

Previo a la disponibilidad del software de administración de pruebas comercial, programar la localización de los instrumentos compartidos entre múltiples interruptores de prueba ejecutando un sistema de prueba en paralelo, requería agregar una cantidad grande de códigos de bajo nivel sincronizados para programar pruebas. Las secciones críticas están con frecuencia conectadas con el código actual, haciendo difícil programar o usar nuevamente secciones en los sistemas de prueba futuros.

Al implementar los sistemas de prueba en paralelo, los cuales mejoran las características incluidas en TestStand de NI, puede controlar sin esfuerzo el que los instrumentos estén compartidos y la sincronización de los múltiples dispositivos bajo prueba. Puede utilizar tipos de sincronización y propiedades de configuración para pruebas a un nivel de prueba individual para manejar que los recursos sean compartidos entre pruebas mientras se lleva a cabo una secuencia. Los pasos de sincronización utilizados en las secuencias de prueba con frecuencia incluyen el cierre, acuerdo, arreglo, notificación, espera y sincronización de lotes. La Figura 5 muestra cómo puede utilizar un paso de cierre mientras prueba dos UUTs.

 

Figura 5. Esta prueba de secuencia que se ejemplifica utiliza una combinación de tipos de pasos de cierre para prevenir que múltiples pruebas tengan acceso al mismo instrumento de manera simultánea.

Para conocer más detalles, vea el documento Beneficios de las Pruebas en Paralelo.

Resumen: Maximizando el Rendimiento en un Sistema de Prueba Automatizado

Al desarrollar un sistema donde el rendimiento es crítico, usted debe elegir el bus con mayor procesamiento, seleccionar un software que tome la ventaja completa de los procesadores más actuales, utilice sincronización con el hardware, y diseñe una arquitectura del sistema que soporte pruebas en paralelo, además de compartir recursos. El tema principal de estas cuatro estrategias es la elección de una plataforma de hardware y software que tome ventaja completa de las últimas tecnologías de PC, como los son PXI y LabVIEW.

Productos y Documentos de NI Relevantes

National Instruments, líder en pruebas automatizadas, está comprometido para proporcionar productos de hardware y software que los ingenieros requieren para crear sistemas de prueba de nueva generación.

Software:

• Marco de Trabajo de Administración de Pruebas NI TestStand
• Entorno de Programación Gráfica LabVIEW
• Software de Medida Interactiva Signal Express

Hardware:

• Instrumentos Modulares (Osciloscopios, Multímetros, RF, Interruptores y más)
• Adquisición de Datos Multifuncional
• Componentes del Sistema PXI (Chasis y Controladores)
• Control de Instrumentos (GPIB, USB, y LAN)

Documentos:
NI ofrece una Guía para Desarrolladores que Diseñan Sistemas de Prueba de Nueva Generación. Esta guía es una colección de documentos fuente diseñados para ayudarle a desarrollar sistemas de prueba que bajen sus costos, incrementen el rendimiento de la prueba, y que puedan actualizarse, según requerimientos futuros. Para descargar las guía completa de desarrolladores (120 páginas), visite ni.com/automatedtest.