Une visite virtuelle du laboratoire IIoT de RTI

"Assurez-vous de leur parler de les systèmes logiciels qui exploitent le laboratoire, » m'a dit mon équipe alors que je me préparais à guider une visite du laboratoire IIoT de RTI dans le cadre de l'édition Silicon Valley de la conférence Connext. Si vous visitez le laboratoire, ce qui ressort, ce sont les rangées et les rangées de matériel, des gros serveurs au Raspberry Pi. Pourtant, les systèmes physiques du laboratoire ne racontent qu'une partie de l'histoire de ce qui se passe derrière le rideau pour construire et tester notre logiciel. Les systèmes logiciels transforment l'espace d'une « collection d'ordinateurs » en un véritable laboratoire. Cette coordination des ressources du laboratoire par les systèmes logiciels internes a évolué et est intégrée dans les processus internes de construction, de test et de support de RTI.

Avant d'entrer dans les détails, permettez-moi de brosser un tableau du type de développement logiciel que notre laboratoire doit prendre en charge. Le logiciel RTI Connext s'exécute sur plus de 100 combinaisons processeur/système d'exploitation/chaîne d'outils différentes, allant des distributions Linux courantes sur les processeurs Intel aux systèmes d'exploitation en temps réel de niche sur des systèmes embarqués personnalisés. Nous prenons en charge diverses technologies de mise en réseau et transports, et interfaçons avec un certain nombre de bases de données. Les bibliothèques RTI Connext prennent en charge le développement en C, C++, Java, C#, Ada, Lua, Python, Javascript et Go. Notre gamme de produits se compose de plus de 20 produits individuels. Nous continuons à prendre en charge et à envoyer des correctifs aux versions logicielles plus anciennes, depuis plus de dix ans, en raison de la nature et des cycles de mise à niveau des systèmes IIoT des clients. Pour soutenir cela, nous avons construit un impressionnant laboratoire IIoT.

Chez RTI, nous hébergeons et exploitons nos propres systèmes de build et de test. Alors que certaines parties peuvent facilement être migrées vers un environnement Atlassian, Amazon Web Services ou Microsoft Azure hébergé, une grande partie du laboratoire ne le peut pas. Jetons un coup d'œil.

Le laboratoire RTI IIoT se compose de trois grands groupes de systèmes :

1. Le cluster de build et de test - exécuter diverses machines virtuelles x86/x64
2. Les machines cibles de test d'entreprise et embarquées - une combinaison de matériel spécial, de systèmes d'exploitation en temps réel et de systèmes moins couramment utilisés
3. Les machines évolutives et performantes - un ensemble de machines de test puissantes et une grande banque de cartes Raspberry Pi.

Le cluster de construction et de test

Chaque jour, les développeurs et le système d'intégration continue lancent de nombreux builds et cycles de test sur notre cluster de build et de test. Ce système est construit à l'aide d'openstack et de ceph pour virtualiser l'environnement de calcul et de stockage. Nous utilisons actuellement Atlassian Bamboo pour l'intégration continue et sommes en train de migrer vers Jenkins. Plus à ce sujet plus tard.

Chaque semaine, nous commençons un cycle complet de build et de test de régression sur toutes nos architectures prises en charge. Cela implique les systèmes virtualisés, ainsi que des tests sur les cibles de test d'entreprise et embarquées.

Tableau de bord du test de régression

Nous utilisons actuellement un ensemble de scripts maison pour automatiser la compilation hebdomadaire. Ces scripts démarrent des compilations natives et croisées, réinitialisent les cartes embarquées, exécutent des tests sur des cibles embarquées et d'entreprise, collectent les résultats et les fournissent dans un tableau de bord que les développeurs peuvent examiner. Faire fonctionner cela sur toutes les architectures n'est pas un mince effort. Notre équipe de plateformes n'est pas seulement experte dans le portage de nos logiciels sur différents systèmes d'exploitation, elle connaît également les particularités de chaque cible embarquée et la manière d'automatiser les tests.

L'entreprise et les machines cibles de test embarquées

Toutes nos cibles de test ne peuvent pas être virtualisées sur notre cluster de build et de test. Par exemple, nous prenons en charge AIX sur les serveurs IBM Power et Solaris sur Sparc. Nous avons même des clients qui utilisent openVMS sur les systèmes DEC Alpha. Lorsqu'un de nos clients a construit un système personnalisé (et coûteux) à l'aide de processeurs Cell, nous avons obtenu quelques consoles de jeu Playstation 3 et exécutons Linux dessus comme alternative moins coûteuse. Ils continuent à fonctionner comme un charme. Nous avons également une variété de versions de MacOS en cours d'exécution et des systèmes Linux Redhawk renforcés de Concurrent.

Diverses cibles OS d'entreprise dans le laboratoire RTI IIoT

La majorité des cibles de test sont des systèmes embarqués. Beaucoup d'entre eux sont des systèmes sur puce. Nous avons l'une des familles de processeurs du laboratoire :x86, PowerPC, MIPS, ARM (y compris Zynq et NVIDA Tegra X2), etc. Nous prenons en charge de nombreux systèmes d'exploitation en temps réel, notamment VxWorks, VxWorks 653, Integrity, LynxOS, QNX, Nucleus, FreeRTOS, Linux temps réel, DEOS et Intime.

Dans certains cas, en particulier lorsqu'il n'y a pas de système équivalent disponible à l'achat, nos clients nous fourniront le système, le système d'exploitation et le package de support de carte (BSP). Dans la plupart des cas, notre équipe de plate-forme intégrera le système et créera les noyaux intégrés. Nous sommes souvent l'un des premiers à essayer de nouveaux BSP ou même le tout nouveau matériel.

Diverses cibles intégrées dans le laboratoire RTI IIoT

Les machines d'évolutivité et de performance

Le troisième groupe de systèmes sont les machines de test d'évolutivité et de performance. Nous avons un ensemble de systèmes x64 puissants, isolés du reste du laboratoire pour mesurer la latence et le débit de notre logiciel à chaque build. Nous utilisons également ces systèmes pour effectuer des tests de découverte et d'autres tests d'évolutivité, en utilisant des cadres de test maison. Par exemple, avec notre cadre de test « Polygraphe », nous pouvons vérifier le protocole de découverte à grande échelle. Il nous permet de répondre à des questions telles que :Est-ce que toutes les applications qui ont besoin de se découvrir le font ? À quoi ressemble la consommation de CPU, de mémoire et de bande passante pendant la phase de découverte ? Combien de temps dure la découverte ?

De plus, nous avons construit un petit cluster Raspberry Pi nous permettant de tester l'évolutivité de notre logiciel dans diverses topologies de réseau. Dans le cadre de l'un de nos projets de recherche, l'équipe de recherche a conçu un système pour déployer et gérer facilement les applications de test et les résultats lors de l'utilisation de nombreuses machines.

Système logiciel pour déployer des applications de test sur un grand nombre de machines

Mise en réseau

Nous testons notre middleware avec une variété de technologies et de topologies de réseau. Nous avons une combinaison de réseaux Ethernet 10/100Mbps, Gigabit et 10 Gbit. Nous avons un système de gestion des câbles très robuste et avons construit un banc d'essai sans fil pour valider la fonctionnalité de mobilité de transport, tout en passant à d'autres réseaux WIFI. Nous avons une petite configuration Infiniband et, dans le passé, nous avons également testé notre middleware sur une liaison satellite. Nous pouvons simuler des paquets perdus ou des paquets corrompus.

Si vous avez l'occasion de visiter le labo, vous découvrirez qu'il est plein de matériel mais pas de monde. Grâce aux commutateurs d'alimentation en réseau et aux serveurs série, les ingénieurs RTI du monde entier peuvent accéder virtuellement et avoir un contrôle total sur chaque sys

[1] [2] 下一页