Accélérez votre mise sur le marché avec les outils professionnels Connext

Lorsque nous avons amené les participants individuels sur le réseau, nous avons rencontré un certain nombre de problèmes. Vous trouverez ci-dessous une description des défis et des outils que nous avons utilisés pour les relever. Parcourez la liste des titres et voyez si vous avez dû déboguer l'un de ces problèmes dans votre système DDS, puis consultez les liens pour découvrir quelques nouveaux conseils. Pendant que vous le faites, réfléchissez à la manière dont vous essaieriez de diagnostiquer les problèmes sans les outils mentionnés.

Problème :Problèmes de configuration réseau

L'équipe d'Oak Ridge National Labs travaillait sur l'interface graphique LabVIEW qui serait l'affichage principal. Leur ordinateur portable ne pouvait pas voir les données d'aucun des clients sur le réseau. Nous avons vérifié les bases pour nous assurer que leur machine était sur le même sous-réseau - vérifiez toujours les bases en premier ! Bien que l'utilitaire ping standard puisse confirmer l'accessibilité de base entre les machines, il ne vérifie pas que les ports nécessaires à la découverte DDS sont ouverts. L'utilitaire rtiddsping fait exactement cela, et il nous a dit en quelques secondes que le pare-feu installé sur leur ordinateur portable fourni par le gouvernement empêchait le trafic de découverte DDS. Pour un excellent aperçu sur la façon de vérifier les bases, consultez ce message de la communauté .

Problème :mon application envoie-t-elle des données ?

Une question courante parmi les fournisseurs utilisant DDS pour la première fois était de savoir si leur application se comportait correctement :envoyait-elle des données aux intervalles appropriés et les données avaient-elles un sens ? Pour une vérification rapide, nous avons utilisé l'utilitaire RTI DDS Spy. Spy fournit un abonné simple qui peut filtrer de manière sélective pour des types et des sujets spécifiques, et il peut imprimer les échantillons individuels qu'il reçoit, vous permettant de voir rapidement les données que votre application écrit. Chaque fournisseur a utilisé DDS Spy comme contrôle de cohérence après avoir initialement lancé son application.

Parfois, une mise à jour du même sujet peut provenir de plusieurs éditeurs du système. Vous ne savez pas lequel a écrit la dernière mise à jour ? Un commutateur de ligne de commande pour Spy ("-showSampleIdentity") vous permet de voir d'où provient une mise à jour.

Spy est une application console qui peut être déployée sur des cibles intégrées pour des tests de base. Sa petite taille, sa rapidité de démarrage et sa simplicité sont ses principaux avantages. Les détails sur l'utilisation sont ici.

Problème :non-concordance du type de données

Un fournisseur a signalé que lors d'un test précédent, il voyait les données de l'une des autres applications, et maintenant ce n'est pas le cas. La console d'administration nous a rapidement montré qu'une incompatibilité de type de données était à blâmer, c'est-à-dire deux sujets portant le même nom mais des types de données différents. Ces types de discordances peuvent être difficiles à diagnostiquer, en particulier pour les grands types avec de nombreux membres. La console d'administration tire parti de l'orientation des données de DDS pour introspecter les types de données tels qu'ils sont compris par chaque application de votre système. Il présente ensuite à la fois une vue simplifiée et une vue « IDL équivalente » qui facilite la comparaison des types dans des volets côte à côte. Ceci est particulièrement utile dans les situations où vous ne disposez pas de l'IDL source de chaque application.

Dans ce cas, un fournisseur ne s'était pas synchronisé avec le référentiel GitHub pour le dernier IDL, il travaillait donc à partir d'une ancienne version du fichier. Ils ont extrait les derniers fichiers de GitHub, rtiddsgen a créé un nouveau code spécifique au type pour eux, et après une rapide recompilation, leur application a pu lire et écrire les sujets mis à jour.

Problème :non-correspondance QoS

En plus de la découverte, les incohérences de qualité de service (QoS) sont le problème le plus courant rencontré par les utilisateurs de DDS lors de l'intégration. Avec autant de boutons à tourner, comment s'assurer que les réglages sont compatibles ? Le projet OpenFMB a eu sa juste part d'inadéquations de QoS au début. La console d'administration les détecte rapidement et vous indique les paramètres QoS spécifiques qui sont en conflit. Vous pouvez même cliquer sur le nom QoS et accéder directement à la documentation. Les informations de QoS partagées lors de la découverte sont utilisées par la console d'administration pour détecter les discordances.

Problème :Le système fonctionne-t-il comme prévu ?

Bien que Spy fournisse une sortie de texte de base pour les données en direct, vous ne pouvez pas battre un graphique pour voir comment les données changent au fil du temps. Pour une visualisation des données plus sophistiquée, nous nous sommes tournés vers la console d'administration. La fonction de visualisation des données intégrée à la console d'administration a été d'une grande aide pour déterminer rapidement le fonctionnement du système dans son ensemble. Cela nous a même permis de faire défiler les données historiques pour mieux comprendre comment nous sommes arrivés à l'état actuel. Pour en savoir plus sur la visualisation des données, regardez cette courte vidéo d'introduction ou cette vidéo approfondie.

Problème :optimisation des performances

En ce qui concerne le réglage des performances, Monitor devrait être votre outil de prédilection. Monitor fonctionne avec une version spéciale des bibliothèques DDS qui publient périodiquement des données de performances en temps réel à partir de votre application. Les bibliothèques de débogage sont peu intrusives et les données sont collectées et présentées par Monitor.

En utilisant Monitor, vous pouvez en savoir plus sur :

[1] [2] 下一页

Points de preuve DDS pour les voitures autonomes RTI 2015 et un aperçu de 2016