Diseñar un banco de pruebas: mecánica, electrónica y software

Un banco de pruebas no es una máquina mecánica a la que se le agregan sensores y luego un programa. Es un solo sistema, en el que cada decisión mecánica tiene consecuencias en el cableado, y cada decisión de cableado en el software. Antes de detallar la metodología que aplico para diseñar un banco llave en mano, conviene revisar el vocabulario y el estado del arte: banco de pruebas, banco de ensayos y banco metrológico no designan exactamente lo mismo.

Banco de pruebas, banco de ensayos, banco metrológico: ¿de qué hablamos?

Los tres términos suelen usarse indistintamente. Sin embargo, las normas permiten distinguirlos según lo que el banco debe producir.

El banco de ensayos realiza ensayos en el sentido de la norma ISO/IEC 17000: determinar una o varias características de un objeto según un procedimiento. Resistencia, envejecimiento, fatiga, ensayos climáticos o de calificación: el producto se somete a solicitaciones y se observa su comportamiento.
El banco de pruebas verifica que un producto cumple con sus requisitos. El resultado esperado suele ser un veredicto, aprobado o rechazado, tanto en desarrollo como al final de una línea de producción. En inglés, test bench designa de forma más amplia cualquier entorno que permite verificar un diseño; en electrónica y en software, incluso puede ser totalmente virtual.
El banco metrológico tiene como objeto la medición misma. Es un sistema de medida en el sentido del Vocabulario Internacional de Metrología (VIM): un conjunto de instrumentos ensamblados para proporcionar valores medidos. Se basa en tres nociones: la calibración, la incertidumbre de medida y la trazabilidad metrológica, es decir, la relación del resultado con una referencia mediante una cadena ininterrumpida y documentada de calibraciones.

En la práctica, la frontera es difusa. Un banco de ensayos necesita una metrología bien controlada para que sus resultados tengan sentido, y un banco metrológico se controla como un banco de pruebas. Los bancos de metrología de los espejos del ELT son un buen ejemplo: la medición es el objetivo, pero se apoya en un sistema de control completo. Los laboratorios que buscan el reconocimiento de sus ensayos y calibraciones se basan en la norma ISO/IEC 17025.

El estado del arte: lo que ha cambiado

Del instrumento al sistema: el banco original era un puesto donde un técnico leía valores en el osciloscopio y el multímetro. Hoy, la adquisición, el control y el registro están automatizados.
Plataformas modulares: controladores en tiempo real, chasis y módulos de adquisición comerciales sustituyen a las electrónicas desarrolladas para un solo banco. Los ejemplos se dan más abajo.
La simulación en el lazo: con el hardware-in-the-loop (HIL), una parte del sistema real se sustituye por un modelo que corre en tiempo real. Así, un controlador puede probarse antes de que exista la máquina que controla.
El software en el centro: secuenciadores de pruebas, entornos de pruebas en tiempo real, lenguajes de script para el análisis, comunicaciones abiertas (TCP/IP, gRPC) con los sistemas del cliente.
Los datos y la trazabilidad: cada resultado debe poder relacionarse con la pieza probada, la configuración del banco y el estado de calibración de sus sensores.
El ciclo de vida: un banco suele durar más que el producto para el que fue diseñado. La modularidad, la configuración fuera del código y la documentación son lo que permite hacerlo evolucionar.

Partir de la necesidad, no de la solución

Lo que el banco debe demostrar: qué magnitud medir, con qué incertidumbre y en qué rango. Es la pregunta que define todo lo demás.
El contexto de uso: en laboratorio o en producción, por un ingeniero de pruebas o por un operador, unas cuantas pruebas al año o varias al día. Una misma necesidad de medición da lugar a dos bancos muy distintos.
Las restricciones del sitio: espacio disponible, alimentación eléctrica, red informática, reglas de seguridad del cliente.

Este trabajo se hace con el cliente, a menudo desde la respuesta a la licitación. Corregir una necesidad mal entendida cuesta mucho más en la aceptación que en la especificación.

Dividir en tres disciplinas, cuidar las interfaces

El banco se divide en tres subsistemas: mecánica, electrónica y software. Cada uno tiene su diseñador, pero las dificultades casi siempre están entre los tres:

Mecánica y electrónica: ubicación de los sensores, paso de los cables, espacio para el gabinete eléctrico, puesta a tierra.
Electrónica y software: lista de canales, tipos de señales, frecuencia de adquisición, comportamiento ante una falla.
Software y mecánica: secuencias de movimiento, topes, funciones de seguridad.

Congelo estas interfaces desde el principio, en un documento compartido por todo el equipo: la lista de canales, en particular, sirve de referencia común para el técnico de cableado y para el desarrollador.

La mecánica: sujetar la pieza, proteger al operador

La estructura debe ser lo bastante rígida para no falsear la medición, y estar aislada de las vibraciones cuando la medición es sensible a ellas.
El montaje de la pieza debe ser repetible: una pieza mal colocada da una medición errónea, incluso con la mejor cadena de adquisición.
El operador debe poder cargar la pieza, acceder a los ajustes e intervenir en mantenimiento sin desarmar el banco.
La seguridad se diseña desde el principio: guardas, paro de emergencia y protecciones, en lugar de agregarlas al final.

El modelo 3D, hecho por ejemplo en FreeCAD, también sirve para verificar el espacio que ocupa el gabinete y el recorrido de los cables.

La electrónica: de la magnitud física a la señal

Los sensores se eligen según la magnitud, el rango y la incertidumbre buscados, y después se define el acondicionamiento adecuado para cada uno.
La adquisición y el control: adquisición rápida para la medición, PLC o controlador en tiempo real para el control y las funciones de seguridad. La elección depende de la frecuencia y del nivel de seguridad requeridos.
El gabinete eléctrico se dibuja con un software de diseño eléctrico, QElectroTech por ejemplo: los esquemas, las borneras y la identificación de los cables forman la documentación de referencia, tanto para el cableado como para el mantenimiento.
El estado seguro: cada salida se cablea para que la ausencia de comando ponga el banco en un estado seguro, incluso si se pierde la comunicación.

El software: controlar, medir, registrar

La secuencia de las pruebas: cada prueba sigue una secuencia descrita, con pasos, criterios de aprobación y respuestas ante las fallas.
La interfaz del operador muestra lo esencial: el estado del banco, el paso en curso y las alarmas. Los ajustes avanzados quedan reservados al ingeniero.
La trazabilidad: cada resultado se registra con la pieza probada, la configuración del banco, la versión del software y la fecha.
La configuración fuera del código: canales, umbrales y secuencias se describen en archivos, para que el banco pueda evolucionar sin recompilar todo.

El lenguaje y las herramientas dependen de los del cliente y de su equipo de mantenimiento. Algunos ejemplos a continuación.

Ejemplos: el hardware de adquisición y de control

Las mismas funciones se encuentran en los principales proveedores. La elección depende de la frecuencia, del entorno del banco y de las herramientas que el cliente ya utiliza.

National Instruments (NI): CompactDAQ (cDAQ) para la medición controlada desde una PC, CompactRIO (cRIO) para el control en tiempo real y el FPGA, PXI para los sistemas de prueba más exigentes.
Dewesoft: sistemas de adquisición (SIRIUS, KRYPTON) operados con el software DewesoftX, e IOLITE, que combina adquisición y control en tiempo real del banco, con salidas analógicas, digitales y EtherCAT.
WAGO: el sistema de E/S modular 750/753, conectado a un bus de campo (EtherCAT, Modbus TCP…) mediante un acoplador, o asociado a un controlador PFC programable en CODESYS.
Gantner Instruments: módulos de E/S y controladores Q.station para la adquisición distribuida, configurados y operados con el software GI.bench, y API para la integración, en particular en Python.

Ejemplos: programar el banco

LabVIEW: un lenguaje gráfico pensado para la adquisición y el control. Una aplicación de banco suele organizarse en lazos paralelos que intercambian mensajes: adquisición, control, interfaz y registro. LabVIEW Real-Time y LabVIEW FPGA despliegan el mismo lenguaje en un cRIO.
NI TestStand: un secuenciador de pruebas (test executive). Encadena pasos que llaman a módulos de código escritos en LabVIEW, C, .NET o Python, compara cada medición con sus límites, ejecuta las pruebas en serie o en paralelo y genera los reportes.
NI VeriStand: un entorno de pruebas en tiempo real, pensado para el hardware-in-the-loop. Los canales, los modelos de simulación y las alarmas se configuran en una definición de sistema, sin programar el lazo en tiempo real; los escenarios se escriben como perfiles de estímulo o secuencias en tiempo real.
Python: muy utilizado para el análisis de datos y la automatización de pruebas. Los proveedores ofrecen sus bibliotecas: nidaqmx para el hardware NI, niveristand para escribir secuencias de VeriStand en Python, así como API de Dewesoft y Gantner.

Un ejemplo mínimo en Python, que lee un voltaje en el primer canal de un módulo NI cDAQ:

import nidaqmx

with nidaqmx.Task() as task:
    task.ai_channels.add_ai_voltage_chan("cDAQ1Mod1/ai0")
    print(task.read())

En un banco, la misma lectura se integra en una secuencia de TestStand o en un script de prueba, con sus límites y su registro.

Integrar, validar, entregar

Las pruebas de aceptación se preparan desde la especificación: cada requisito de las especificaciones tiene una prueba que lo verifica.
La integración se hace por etapas: cada subsistema se prueba por separado antes del banco completo, para encontrar una falla donde está.
La documentación entregada incluye los planos, los esquemas, el manual de usuario y los reportes de aceptación.
La capacitación de los usuarios forma parte de la entrega: un banco que nadie sabe usar no está terminado.

Un ejemplo: un sistema de prueba de frenado aeronáutico

En STYREL, modernizamos el sistema de prueba de frenado de un cliente del sector aeronáutico. Sus retos: garantizar un desempeño en tiempo real, hacer confiables los intercambios de datos y poder hacer evolucionar él mismo sus algoritmos de frenado.

Una arquitectura de software híbrida sobre una plataforma cRIO: LabVIEW para la gestión de los datos y C embebido para los procesamientos en tiempo real. Combina desempeño, determinismo y modularidad.
Una API dedicada asegura una comunicación confiable por TCP/IP con el sistema de supervisión del cliente.
Los resultados: una respuesta en tiempo real inferior a 1 ms, una precisión inferior a 10 µs y cuatro veces más escenarios de prueba.
Un proyecto de principio a fin, desde la prueba de concepto hasta la puesta en servicio, pasando por el diseño, el desarrollo y la validación, con metodología ágil (Scrum).

Este ejemplo resume la metodología: partir de los retos del cliente, elegir la arquitectura en consecuencia y dejarle el control de lo que debe evolucionar.

Para recordar

Un banco de pruebas se diseña como un solo sistema: los problemas vienen sobre todo de las interfaces entre mecánica, electrónica y software.
El contexto de uso en las instalaciones del cliente cuenta tanto como la medición misma.
La seguridad, la trazabilidad y la aceptación se preparan desde el inicio del proyecto, no al final.

Para saber más

Dos artículos detallan partes de esta metodología: cRIO y WAGO en EtherCAT para la adquisición y el control, y Python y LabVIEW para el software.

BIPM, Vocabulario Internacional de Metrología (VIM), JCGM 200:2012, bipm.org; ISO, ISO/IEC 17025:2017, Requisitos generales para la competencia de los laboratorios de ensayo y calibración, iso.org