Acelere su tiempo de comercialización con las herramientas profesionales de Connext

Cuando trajimos a los participantes individuales a la red, encontramos varios problemas. A continuación, se incluye una descripción de los desafíos y las herramientas que utilizamos para abordar cada uno. Escanee la lista de encabezados y vea si ha tenido que depurar alguno de estos problemas en su sistema DDS, luego consulte los enlaces para conocer algunos consejos nuevos. Mientras lo hace, piense en cómo trataría de diagnosticar los problemas sin las herramientas mencionadas.

Problema:problemas de configuración de la red

El equipo de Oak Ridge National Labs estaba trabajando en la GUI de LabVIEW que sería la pantalla principal. Su computadora portátil no pudo ver los datos de ninguno de los clientes en la red. Verificamos los conceptos básicos para asegurarnos de que su máquina estuviera en la misma subred; ¡siempre verifique los conceptos básicos primero! Si bien la utilidad de ping estándar puede confirmar la accesibilidad básica entre máquinas, no verifica que los puertos necesarios para el descubrimiento de DDS estén abiertos. La utilidad rtiddsping hace exactamente eso, y nos dijo en segundos que el firewall instalado en su computadora portátil emitida por el gobierno estaba impidiendo el tráfico de descubrimiento de DDS. Para obtener un resumen sobre cómo verificar los conceptos básicos, consulte esta publicación de la comunidad .

Problema:¿Mi aplicación envía datos?

Una pregunta común entre los proveedores que usaban DDS por primera vez era si su aplicación se estaba comportando correctamente:¿estaba enviando datos en los intervalos adecuados y los datos tenían sentido? Para una comprobación rápida, utilizamos la utilidad RTI DDS Spy. Spy proporciona un suscriptor simple que puede filtrar selectivamente por tipos y temas específicos, y puede imprimir las muestras individuales que recibe, lo que le permite ver rápidamente los datos que está escribiendo su aplicación. Todos los proveedores utilizaron DDS Spy como verificación de cordura después de iniciar inicialmente su aplicación.

A veces, una actualización del mismo tema puede provenir de varios editores en el sistema. ¿No estás seguro de cuál escribió la última actualización? Un interruptor de línea de comando para Spy ("-showSampleIdentity") le permite ver dónde se originó una actualización.

Spy es una aplicación de consola que se puede implementar en objetivos integrados para pruebas básicas. Su reducido tamaño, rápida puesta en marcha y sencillez son sus principales ventajas. Los detalles sobre el uso están aquí.

Problema:el tipo de datos no coincide

Un proveedor informó que en una prueba anterior estaba viendo datos de una de las otras aplicaciones, y ahora no. La Consola de administración nos mostró rápidamente que la culpa era de una falta de coincidencia de tipos de datos, es decir, dos temas con el mismo nombre pero tipos de datos diferentes. Estos tipos de desajustes pueden ser difíciles de diagnosticar, especialmente para tipos grandes con muchos miembros. La Consola de administración aprovecha la centralidad de datos de DDS para introspectar los tipos de datos tal como los entiende cada aplicación en su sistema. A continuación, presenta una vista simplificada y una vista "IDL equivalente" que facilita la comparación de los tipos en paneles uno al lado del otro. Esto es especialmente valioso en situaciones en las que no tiene el IDL de origen de todas las aplicaciones.

En este caso, un proveedor no se había sincronizado con el repositorio de GitHub para el IDL más reciente, por lo que estaban trabajando desde una versión anterior del archivo. Extrajeron los archivos más recientes de GitHub, rtiddsgen creó un nuevo código específico de tipo para ellos y, después de una recompilación rápida, su aplicación pudo leer y escribir los temas actualizados.

Problema:falta de coincidencia de QoS

Junto al descubrimiento, las discrepancias en la calidad de servicio (QoS) son el problema más común que experimentan los usuarios de DDS durante la integración. Con tantas perillas para girar, ¿cómo se asegura de que los ajustes sean compatibles? El proyecto OpenFMB tuvo una buena cantidad de desajustes de QoS al principio. La Consola de administración los detecta rápidamente y le indica las configuraciones específicas de QoS que están en conflicto. Incluso puede hacer clic en el nombre de QoS e ir directamente a la documentación. La Consola de administración utiliza la información de QoS compartida durante el descubrimiento para detectar discrepancias.

Problema:¿Funciona el sistema como se esperaba?

Si bien Spy proporciona una salida de texto básica para datos en vivo, no hay nada mejor que un gráfico para ver cómo cambian los datos con el tiempo. Para una visualización de datos más sofisticada, recurrimos a la Consola de administración. La función de visualización de datos incorporada en la Consola de administración fue de gran ayuda para determinar rápidamente cómo funcionaba el sistema en su conjunto. Incluso nos permitió desplazarnos por los datos históricos para comprender mejor cómo llegamos al estado actual. Para obtener más información sobre la visualización de datos, vea este breve video de introducción o este video de análisis en profundidad.

Problema:ajuste del rendimiento

Cuando se trata de ajustar el rendimiento, Monitor debe ser su herramienta de referencia. Monitor funciona con una versión especial de las bibliotecas DDS que publican periódicamente datos de rendimiento en tiempo real de su aplicación. Las bibliotecas de depuración son mínimamente intrusivas, y Monitor recopila y presenta los datos.

Con Monitor, puede aprender sobre:​​

• Estadísticas de transmisión y recepción
• Plazos incumplidos
• Marcas de agua alta en cachés
• Discordancias de QoS
• Conflictos de tipos de datos
• Muestras perdidas o rechazadas
• Pérd

  [1] [2] 下一页

  Puntos de prueba DDS para vehículos autónomos 2015 de RTI y un vistazo a 2016