Selección de interfaz de bus de comunicación satelital

Por lo general, los ingenieros de pruebas pueden estar de acuerdo en la gran importancia del dicho "elija la herramienta adecuada para el trabajo". Esto se debe a que usar la herramienta equivocada se puede perder tiempo y comprometer la calidad, mientras que una herramienta adecuada puede llevar al resultado correcto en una fracción del tiempo.

Las herramientas principales vienen en forma de instrumentación de medidas y estímulo cuando se construyen equipos electrónicos de soporte en tierra (EGSE) o STEs de verificación especializada (SCOS, STE significa equipo de prueba especializado) para pruebas de integración, verificación y fabricación de alto volumen. Estos instrumentos incluyen productos conocidos como multímetros digitales (DMM), osciloscopios y generadores de forma de onda, así como una variedad de productos nuevos y cambiantes como transceptores vectoriales de señales y osciloscopios multifuncionales. Elegir la herramienta adecuada para el trabajo es mucho más fácil de decir que de hacer, especialmente cuando se trata de navegar y evaluar las ventajas y desventajas que están en juego. Esto se aplica tanto a instrumentos comerciales como especializados; sin embargo, las interfaces de bus de comunicación satelital por lo general no se consideran con el mismo nivel de rigor.

Al considerar la lista de instrumentación que debe incluirse en el EGSE utilizado para la prueba de validación o integración, los ingenieros de pruebas están acostumbrados a consultar sus planes de pruebas y evaluar la instrumentación disponible en el mercado para garantizar que se instalen los instrumentos correctos para proporcionar una cobertura completa de medidas para cubrir los requisitos del plan de pruebas.

Muchas veces, el plan de pruebas para un dispositivo bajo prueba (DUT) en particular requiere pasos adicionales para poner el DUT en un estado particular o enviarle un comando y escuchar la respuesta esperada; esto es especialmente cierto cuando se prueban controladores de vuelo y de sistema. Estos pasos pueden incluir realizar de control de garantía de calidad, realizar un subconjunto de los pasos de verificación del diseño en el propio bus de aviónica o grabar respuestas para su análisis o reproducción posterior. Para garantizar que esta funcionalidad esté integrada en el EGSE, los ingenieros de pruebas por lo general buscan qué protocolo(s) utiliza el DUT para la comunicación, así como los productos comerciales para encontrar un instrumento que se ajuste a sus necesidades.

Dependiendo de la combinación de la plataforma de activos de prueba y el DUT específico, hay una amplia variedad de opciones para elegir un instrumento de interfaz de bus de aviónica en particular. Al considerar los protocolos más comunes, como MIL-STD-1553, ARINC-429 y SpaceWire hay varios proveedores de instrumentos en el mercado que tienen opciones listas para usar que pueden cubrir esas necesidades. Sin embargo, al considerar buses centrales o de alta velocidad como Fibre Channel (específicamente SpaceFibre), Serial RapidIO (SRIO), AFDX, bus de datos de alta velocidad (HSDB) e IEEE-1394b o buses específicos de la aplicación como ARINC-708, ARINC-717 o ARINC-818; las opciones se vuelven mucho más complejas e implican más consideraciones. 

Muchas interfaces de bus, como SpaceWire, se han vuelto tan predominante que los instrumentos de interfaz se han convertido en productos básicos. Se ha vuelto más rentable para los proveedores de equipos de pruebas integrar las capas física, de enlace de datos y de red en un dispositivo de función fija. Por ejemplo, STAR-Dundee ofrece múltiples módulos PXI para conectar y conmutar señales de bus SpaceWire. Al igual que los instrumentos para otros protocolos de comunicación ampliamente adoptados, como GPIB, a nivel de hardware, estos instrumentos a menudo tienen una arquitectura similar de un proveedor a otro para cumplir con el estándar específico. 

Donde un proveedor de equipos de pruebas puede diferenciar su producto sobre otro viene en las capas de datos más altas del modelo de interconexión de sistemas abiertos (OSI) donde se implementan características o capacidades específicas para soportar el protocolo. Estos incluyen detección de errores, flexibilidad de programación, estampa de tiempo, registro de datos e inserción de fallas, solo por nombrar algunos. Algunos fabricantes también proporcionan acceso a los datos en cada capa OSI individual para monitoreo o depuración. Para los requisitos de pruebas de integración y validación a nivel de sistema, muchas de las características que son distintas a menudo no son tan críticas para que la aplicación tenga éxito, por lo que la decisión generalmente recae en la preferencia del ingeniero.

Figura 1. Vista simplificada de las capas OSI de ARINC-664p7/AFDX

Cuando un sistema de pruebas requiere interfaces de protocolo de alta velocidad/central o específico de la aplicación, una decisión de selección que antes era simple se vuelve mucho más desafiante. Los ingenieros de pruebas a menudo pasan por alto la complejidad asociada con la integración de estos protocolos en sus sistemas de pruebas. Uno de los principales desafíos que surgen con estos protocolos de mayor rendimiento es pasar desde la transmisión de datos en paralelo a la serial. 

Los estándares seriales han ido ganando popularidad debido a que la limitación física en las velocidades de reloj de los buses paralelos es de alrededor de 1 GHz a 2 GHz; el desfase que introduce el reloj individual y las líneas de datos puede causar errores de bits a velocidades más rápidas. En cambio, los buses seriales de alta velocidad envían información codificada que contiene datos e información del reloj en una o más señales diferenciales, evitando las limitaciones de velocidad de los buses paralelos. Además, utilizar transceptores de hardware serial de alta velocidad y especializados con capacidades avanzadas como recuperación de reloj, pre-énfasis y ecualización aumentan aún más estas ventajas. 

Los diseños para interfaces de protocolo serial de alta velocidad se prestan muy bien para ejecutarse en la última tecnología de FPGA. Por ejemplo, los transceptores de múltiples gigabits en los FPGAs de Xilinx más recientes, pueden funcionar a más de 30 Gb/s, lo que los convierte en candidatos ideales para actuar como procesador de datos para un protocolo de comunicación. Además de la complejidad del diseño del hardware para estos instrumentos, el protocolo IP en sí también es más complejo que un instrumento comercial, ya que los protocolos tienden a tener muchas más funciones y requisitos de datos más estrictos debido a la complejidad requerida para manejar el aumento de un orden de magnitud en las velocidades de datos. 

Cuando se trata de integrar una interfaz de protocolo de alta velocidad/central o específica de la aplicación en particular en un EGSE, los ingenieros a menudo se enfrentan a un par de opciones.

• La opción 1 es consultar productos comerciales y encontrar un proveedor que ofrezca la interfaz en cuestión. Una vez más, debido a la complejidad del diseño del hardware e IP, los ingenieros a menudo deben trabajar con dos proveedores: uno para el hardware serial de alta velocidad y otro para el protocolo IP principal.

• La opción 2 es aprovechar el diseño del equipo de validación interno para el DUT en cuestión, que combina un núcleo de IP con una tarjeta de evaluación de FPGA personalizada o comercial e integrarla en el EGSE. Si bien aprovechar un diseño interno personalizado puede parecer atractivo, existen riesgos ocultos que pueden aumentar sustancialmente la carga del mantenimiento con el tiempo.

Figura 2. Administrar el ciclo de vida de un sistema de pruebas "de creación interna"

Para ilustrar esto, la Figura 2 muestra un ejemplo de la vida útil de un sistema de pruebas y los eventos que afectan los costos de mantenimiento de ese sistema a lo largo del tiempo. Una vez que el EGSE esté completamente diseñado, considere que un componente de su tarjeta personalizada llega al final de su vida útil (EOL). Esto es de esperarse, ya que los ciclos de actualización de la tecnología de semiconductores tienden a reflejar el mercado comercial. Y es especialmente probable si se adopta un diseño del equipo de validación, ya que es probable que las preocupaciones sobre el ciclo de vida no se hayan incluido en sus requisitos de diseño. 

En una situación como esta, la compra de por vida de ese componente y la administración de repuestos o la búsqueda de un reemplazo y la revalidación del diseño del hardware son esencialmente las únicas opciones. O considere una actualización del sistema operativo, como un cambio de versión de Windows, o tal vez un cambio a Linux. Luego, los controlador se deben reescribir y revalidar el diseño del software. ¿Qué sucede si los requisitos para el probador cambian con el tiempo o si es necesario añadir nuevas funciones? Esto podría requerir un rediseño del firmware o del software, o incluso de la capa física, dependiendo de los requisitos del dispositivo bajo prueba. Y finalmente, ¿qué pasa cuando el FPGA llega al final de su vida útil? No existe una ruta de actualización sencilla para estos componentes, por lo que a menudo se requiere un rediseño completo. 

Estos son sucesos muy realistas para un sistema de pruebas que, en la industria aeroespacial y de defensa, probablemente tendrá que durar décadas. Muchas veces, cuando ocurren estos desafíos de obsolescencia, las personas que diseñaron el EGSE original y los programas de software de prueba que se ejecutan en ellos ya no están disponibles para ayudar con los programas de mantenimiento. Finalmente, el costo inicial del diseño es solo un porcentaje muy pequeño del costo del sistema de pruebas durante su vida útil.

En cambio, siempre que sea posible, los ingenieros deben considerar la Opción 1: una solución basada en productos comerciales, específicamente una diseñada para usarse en aplicaciones de pruebas y medidas. Incluso con la capacidad interna para diseñar y administrar la compleja IP de software requerida para interactuar con el protocolo de comunicación satelital, la carga adicional por mantenimiento y sostenimiento del hardware personalizado significa que un enfoque comercial reducirá el costo total de las pruebas. 

Durante décadas, la industria aeroespacial y de defensa ha utilizado la instrumentación modular y el software de aplicación de NI para reducir el costo y el riesgo asociados con las pruebas y el soporte de sus productos. Durante ese tiempo, NI fue pionera en la plataforma PXI y desde entonces ha lanzado más de 600 módulos PXI diferentes que van desde DC hasta onda milimétrica. Además de la instrumentación tradicional, las soluciones de pruebas de integración, comprobación y fabricación de alto volumen proporcionadas por NI, nuestra red de socios y los más de 70 miembros de PXISA que proporcionan elementos de la plataforma PXI, como STAR-Dundee, ofrecen la más extensa cobertura de interfaces de bus basadas en PXI y mantienen la flexibilidad para elegir la "herramienta adecuada para el trabajo".

Interfaces de aviónica digital para pruebas de fabricación y almacén

Interfaces genéricas:

• MIL-STD-1553 
• RS-232/422/485 
• ARINC-429 
• CANbus 

Interfaces de alta velocidad/centrales:

• Canal de fibra (específicamente SpaceFibre)
• Serial RapidIO 
• ARINC-664p7/AFDX 
• 1394b FireWire 
• Ethernet (hasta 40 GigE) 

Software específico de aplicación

• ARINC-708 
• ARINC-717 
• ARINC-818 
• SpaceWire 
• DVI

Hay casos en los que un ingeniero de pruebas puede creer que un enfoque comercial no es viable y que se requiere una ingeniería personalizada. Un ejemplo citado a menudo, es probar un DUT que se comunica a través de una versión personalizada de un protocolo en particular. Sin embargo, incluso en estos casos, se recomienda evitar el diseño personalizado para reducir riesgos en el cronograma y la carga por un mantenimiento futuro del EGSE de pruebas. Para aprender más sobre construir sistemas completos de pruebas de electrónica para el espacio, incluyendo la integración del hardware de interfaz de bus de comunicación comercial en sus sistemas de pruebas para resolver los desafíos del diseño personalizado, lea la nota de aplicación.