Eine virtuelle Tour durch das IIoT-Labor von RTI

"Erzählen Sie ihnen unbedingt davon die Softwaresysteme, die das Labor betreiben, “ erzählte mir mein Team, als ich mich darauf vorbereitete, im Rahmen der Silicon Valley-Ausgabe der Connext Conference eine Tour durch das IIoT Lab von RTI zu führen. Wer das Labor besucht, sticht reihenweise Hardware ins Auge, von großen Servern bis hin zum Raspberry Pi. Doch die physischen Systeme im Labor erzählen nur einen Teil der Geschichte dessen, was hinter den Kulissen passiert, um unsere Software zu bauen und zu testen. Die Softwaresysteme verwandeln den Raum von einer "Ansammlung von Computern" in ein echtes Labor. Diese Koordination der Laborressourcen durch interne Softwaresysteme hat sich weiterentwickelt und ist in die RTI-internen Build-, Test- und Supportprozesse integriert.

Bevor wir auf die Details eingehen, lassen Sie mich ein Bild von der Art der Softwareentwicklung zeichnen, die unser Labor unterstützen muss. Die RTI Connext-Software läuft auf über 100 verschiedenen Prozessor/Betriebssystem/Toolchain-Kombinationen, von gängigen Linux-Distributionen auf Intel-Prozessoren bis hin zu Nischen-Echtzeitbetriebssystemen auf benutzerdefinierten eingebetteten Systemen. Wir unterstützen verschiedene Netzwerktechnologien und Transporte und haben Schnittstellen zu einer Reihe von Datenbanken. RTI Connext-Bibliotheken unterstützen die Entwicklung in C, C++, Java, C#, Ada, Lua, Python, Javascript und Go. Unsere Produktsuite besteht aus über 20 Einzelprodukten. Aufgrund der Beschaffenheit und der Upgrade-Zyklen der IIoT-Systeme der Kunden unterstützen und versenden wir weiterhin Patches für ältere Softwareversionen, die über zehn Jahre zurückreichen. Um dies zu unterstützen, haben wir ein beeindruckendes IIoT-Labor aufgebaut.

Bei RTI hosten und betreiben wir unsere eigenen Build- und Testsysteme. Während einige Teile problemlos in eine gehostete Atlassian-, Amazon Web Services- oder Microsoft Azure-Umgebung migriert werden können, ist dies bei einem Großteil des Labors nicht möglich. Werfen wir einen Blick darauf.

Das RTI IIoT-Labor besteht aus drei großen Gruppen von Systemen:

1. Der Build- und Testcluster - Ausführen verschiedener virtueller x86/x64-Maschinen
2. Die Unternehmens- und eingebetteten Testzielcomputer - eine Kombination aus spezieller Hardware, Echtzeit-Betriebssystemen und weniger verbreiteten Systemen
3. Die Skalierbarkeits- und Leistungsmaschinen - ein Set leistungsstarker Testmaschinen und eine große Bank von Raspberry Pi-Boards.

Das Build- und Test-Cluster

Jeden Tag starten Entwickler und das Continuous Integration-System zahlreiche Builds und Testzyklen in unserem Build- und Testcluster. Dieses System wird mit Openstack und Ceph erstellt, um die Rechen- und Speicherumgebung zu virtualisieren. Wir verwenden derzeit Atlassian Bamboo für die kontinuierliche Integration und sind dabei, auf Jenkins zu migrieren. Mehr dazu später.

Wöchentlich starten wir einen vollständigen Build- und Regressionstestzyklus für alle unsere unterstützten Architekturen. Dies umfasst die virtualisierten Systeme sowie Tests auf den Enterprise- und eingebetteten Testzielen.

Regressionstest-Dashboard

Wir verwenden derzeit eine Reihe von selbst erstellten Skripten, um den wöchentlichen Build zu automatisieren. Diese Skripte starten native und Cross-Kompilierungen, setzen eingebettete Boards zurück, führen Tests auf eingebetteten und Unternehmenszielen durch, sammeln die Ergebnisse und stellen sie in einem Dashboard zur Überprüfung durch die Entwickler bereit. Dies über alle Architekturen hinweg zum Laufen zu bringen, ist kein geringer Aufwand. Unser Plattform-Team ist nicht nur Experte in der Portierung unserer Software auf verschiedene Betriebssysteme, sondern kennt sich auch mit den Besonderheiten jedes eingebetteten Targets und der Automatisierung der Tests aus.

Die Enterprise- und Embedded-Testzielmaschinen

Nicht alle unsere Testziele können in unserem Build- und Testcluster virtualisiert werden. Wir unterstützen beispielsweise AIX auf IBM Power-Servern und Solaris auf Sparc. Wir haben sogar Kunden, die openVMS auf DEC Alpha-Systemen verwenden. Als einer unserer Kunden ein benutzerdefiniertes (und teures) System mit Cell-Prozessoren baute, haben wir uns ein paar Playstation 3-Spielekonsolen besorgt und laufen auf ihnen Linux als kostengünstigere Alternative. Sie funktionieren weiterhin wie ein Zauber. Wir haben auch eine Vielzahl von MacOS-Versionen und gehärtete Redhawk Linux-Systeme von Concurrent.

Verschiedene Enterprise OS Targets im RTI IIoT Lab

Die Mehrzahl der Testziele sind eingebettete Systeme. Viele davon sind Systeme auf einem Chip. Wir haben eine der meisten Prozessorfamilien im Labor:x86, PowerPC, MIPS, ARM (einschließlich Zynq und NVIDA Tegra X2) usw. Wir unterstützen viele Echtzeit-Betriebssysteme, einschließlich VxWorks, VxWorks 653, Integrity, LynxOS, QNX, Nucleus, FreeRTOS, Echtzeit-Linux, DEOS und Intime.

In einigen Fällen, insbesondere wenn kein gleichwertiges System für uns zum Kauf zur Verfügung steht, stellen uns unsere Kunden das System-, Betriebssystem- und Board-Support-Paket (BSP) zur Verfügung. In den meisten Fällen integriert unser Plattformteam das System und baut die eingebetteten Kernel. Oft sind wir einer der Ersten, die neue BSPs oder sogar die brandneue Hardware ausprobieren.

Verschiedene eingebettete Targets im RTI IIoT Lab

Die Skalierbarkeits- und Leistungsmaschinen

Die dritte Gruppe von Systemen sind die Skalierbarkeits- und Leistungstestmaschinen. Wir verfügen über eine Reihe leistungsstarker x64-Systeme, die vom Rest des Labors isoliert sind, um die Latenz und den Durchsatz unserer Software bei jedem Build zu messen. Wir verwenden diese Systeme auch, um Discovery- und andere Skalierbarkeitstests durchzuführen, indem wir selbst erstellte Test-Frameworks verwenden. Mit unserem Test-Framework „Polygraph“ können wir beispielsweise das Discovery-Protokoll im großen Maßstab verifizieren. Es ermöglicht uns, Fragen zu beantworten wie:Tun alle Anwendungen, die sich gegenseitig entdecken müssen, dies? Wie sieht der CPU-, Speicher- und Bandbreitenverbrauch während der Discovery-Phase aus? Wie lange dauert die Entdeckung?

Zusätzlich haben wir einen kleinen Raspberry-Pi-Cluster gebaut, mit dem wir die Skalierbarkeit unserer Software in verschiedenen Netzwerktopologien testen können. Im Rahmen eines unserer Forschungsprojekte hat das Forschungsteam ein System entwickelt, um die Testanwendungen und -ergebnisse bei Verwendung vieler Maschinen einfach bereitzustellen und zu verwalten.

Softwaresystem zum Bereitstellen von Testanwendungen auf einer großen Anzahl von Maschinen

Netzwerk

Wir testen unsere Middleware mit einer Vielzahl von Netzwerktechnologien und Topologien. Wir haben eine Kombination aus 10/100Mbps, Gigabit und 10 Gbit Ethernet Netzwerken. Wir verfügen über ein sehr robustes Kabelmanagementsystem und haben eine drahtlose Testumgebung gebaut, um die Transport Mobility-Funktion zu validieren, während wir zu anderen WIFI-Netzwerken wechseln. Wir haben ein kleines Infiniband-Setup und haben unsere Middleware in der Vergangenheit auch über eine Satellitenverbindung getestet. Wir können verworfene Pakete oder beschädigte Pakete simulieren.

Wenn Sie die Gelegenheit haben, das Labor zu besuchen, werden Sie feststellen, dass es voller Geräte, aber nicht voller Menschen ist. Über vernetzte Netzschalter und serielle Server können RTI-Ingenieure auf der ganzen Welt virtuell auf jedes System im Labor zugreifen und die volle Kontrolle darüber haben.

Das Build-System der nächsten Generation

Unsere aktuelle Build- und Testinfrastruktur hat uns in den letzten Jahren gute Dienste geleistet. Wir haben jedoch sein Potenzial erreicht. Wir sind dabei, ein neues Build-System aufzubauen, das Folgendes ermöglicht:

• Das Engineering-Team soll

  [1] [2] 下一页

  Daten für alle:Ist die Demokratisierung von Patientendaten die Zukunft? Wie datenzentrierte Gateways bei der Skalierung von IIoT-Systemen helfen