Time-to-Market beschleunigen mit RTI Connext DDS Professional Tools

Nur zwei Wochen blieben vor der Demo.

Wir hatten eine einzelne, hochkarätige Gelegenheit, ein voll funktionsfähiges Microgrid-Control-System zu liefern, das:

• Auf Intel und ARM Prozessoren laufen musste
• Linux und Windows Platforms targeten musste
• Applikationen in C, C++, Java, Scala, Lua und LabVIEW einschloss
• Mit Legacy-Equipment via ModBus und DNP3 Protokollen kommunizieren musste
• Echtzeit-Control ausführen musste bei Erfüllung aller obigen Anforderungen

In diesem Post teile ich die realen Herausforderungen, denen wir gegenüberstanden, und wie die in RTI Connext DDS Professional enthaltenen Tools uns halfen, Integrationsprobleme in nur ein paar Tagen zu lösen. Ich highlight häufige Probleme und die spezifischen RTI-Tools, die jedes adressierten, und liefere Links zu unterstützenden Videos und Artikeln für tiefere Einblicke. Mein Ziel ist, Ihnen einen praktischen Startpunkt für die Anwendung von RTI-Tools zur Beschleunigung Ihrer DDS-Entwicklung zu geben.

The Big Demo

Dies war die erste funktionierende Demonstration des Smart Grid Interoperability Panels Open Field Message Bus (OpenFMB), ein neuer Ansatz für Edge-Grid-Device-Control mit IoT-Technologien wie DDS.

Unten ist ein Blockdiagramm des Systems, das Hardware-Architekturen, Betriebssysteme und Programmiersprachen zeigt:

Als wir jeden Teilnehmer online brachten, stießen wir auf diverse Herausforderungen. Die folgenden Sektionen beschreiben jedes Problem und die Tools, die wir zur Lösung nutzten. Scannen Sie die Überschriften, ob Sie ähnliche Probleme in Ihrem DDS-System hatten, dann klicken Sie Links für neue Troubleshooting-Techniken. Überlegen Sie, wie Sie diese Issues ohne die genannten Tools diagnostiziert hätten.

Problem: Netzwerk-Konfigurationsprobleme

Tools: RTI DDS Ping

Das Oak Ridge National Labs Team baute ein LabVIEW GUI als primäres Display. Ihr Laptop sah Daten von keinem der vernetzten Clients. Wir verifizierten zuerst, dass die Maschine im gleichen Subnetz war – der klassische „Check the Basics“-Schritt. Während das Standard-Ping-Utility grundlegende Erreichbarkeit bestätigt, prüft es nicht, ob DDS Discovery Ports offen sind. Das rtiddsping Utility macht genau das und offenbarte in Sekunden, dass eine government-issued Laptop-Firewall DDS Discovery Traffic blockierte. Für einen gründlichen Guide zu Basisdiagnostik siehe diesen Community Post.

Problem: Publiziert meine Applikation Daten?

Tools: Spy, Admin Console

Eine häufige Frage unter Vendors, die neu zu DDS sind: Verhält sich meine Applikation korrekt? Publiziert sie Daten im erwarteten Intervall, und machen die Daten Sinn? Wir nutzten RTI DDS Spy, einen leichten Subscriber, der für spezifische Typen und Topics filtern und jedes empfangene Sample printen kann. Jeder Vendor führte einen schnellen Sanity Check mit Spy unmittelbar nach Launch ihrer Applikation durch.

Wenn das gleiche Topic von mehreren Publishern geupdatet wird, offenbart der „-showSampleIdentity“ Switch, welcher Publisher das neueste Sample sendete.

Spy ist eine Console App, die auf Embedded Targets für Basis-Testing laufen kann. Sein kleiner Footprint, schneller Startup und Simplicity machen es ideal für schnelle Verifikation. Detaillierte Usage-Instruktionen sind hier verfügbar.

Problem: Datentyp-Mismatch

Tools: Admin Console, Monitor

Ein Vendor reportete, dass nach einem vorherigen Test sie Daten von einer anderen Applikation sehen konnten, aber während der Demo verschwanden die Daten. Admin Console identifizierte sofort einen Datentyp-Mismatch – zwei Topics teilten den gleichen Namen, waren aber mit unterschiedlichen IDL-Strukturen definiert. Solche Mismatches sind schwer zu detektieren, besonders bei großen, komplexen Typen. Admin Console nutzt DDS' datenzentrische Natur, um die von jedem Participant verstandenen Datentypen zu introspektieren, und präsentiert sowohl eine vereinfachte View als auch eine „equivalent IDL“ View für Side-by-Side-Vergleich. Unverzichtbar, wenn Sie nicht den Source-IDL für jede Applikation haben.

In diesem Fall nutzte der Vendor einen veralteten IDL von einem älteren GitHub Commit. Nach Pull der neuesten Files, generierte rtiddsgen aktualisierten typ-spezifischen Code, und ein schnelles Recompile stellte volle Kompatibilität wieder her.

Problem: QoS Mismatch

Tools: Admin Console, Monitor

Jenseits Discovery sind QoS Mismatches das häufigste Integrationsissue für DDS-User. Mit so vielen Knobs zu setzen, wie sichert man Kompatibilität? Das OpenFMB Projekt stieß initial auf mehrere QoS Mismatches. Admin Console detektiert diese schnell und highlightet die konfligierenden Settings. Sie können auf den QoS-Namen klicken, um direkt zur Dokumentation zu springen. QoS-Informationen, die während Discovery ausgetauscht werden, erlauben Admin Console, Mismatches automatisch zu flaggen.

Problem: System Performance verifizieren

Tools: Admin Console, Monitor

Während Spy rohen Text-Output liefert, gibt Visualisierung von Daten über Zeit ein klareres Bild von Systemverhalten. Admin Console's eingebaute Datenvisualisierung half uns, Overall-System-Performance schnell zu assessen und durch Historical Data zu scrollen, um den Current State zu traceen. Für ein kurzes Intro-Video siehe dieses Video, für tiefere Tiefe dieses Video.

Problem: Performance Tuning

Tools: Monitor, Admin Console

Für Performance Tuning ist Monitor das Tool der Wahl. Es arbeitet mit einer speziellen Version der DDS Libraries, die periodisch Echtzeit-Performance-Metriken aus Ihrer Applikation publizieren. Die Debug-Libraries sind minimal intrusiv, und Monitor aggregiert die Daten für Analyse.

Mit Monitor können Sie inspizieren:

• Transmissions- und Rezeptionsstatistiken
• Verpasste Deadlines
• Cache High-Water Marks
• QoS Mismatches
• Datentyp-Konflikte
• Verlorene oder abgelehnte Samples
• Liveliness Loss

Viele QoS Settings werden nicht während Discovery advertised, da sie lokales Resource Management und Performance Tuning betreffen. Monitor lässt Sie diese ebenfalls untersuchen. Sehen Sie dieses Intro-Video für eine schnelle Tour.

Problem: Daten im Flug transformieren

Tools: Prototyper mit Lua, DDS Toolkit für LabVIEW

Wir brauchten ein großes GUI, um Microgrid State in Echtzeit anzuzeigen. Oak Ridge National Labs bot an, das GUI in LabVIEW zu bauen. Der DDS Toolkit für LabVIEW lässt Sie DDS Daten abrufen und in LabVIEW VIs nutzen. Allerdings unterstützt der Toolkit keine Arrays von Sequenzen, die Teil des OpenFMB Datenmodells sind. Wir brauchten eine schnelle Lösung, die diese komplexen Typen lesen konnte.

Prototyper mit Lua, ein neues Feature in Connext DDS Pro 5.2, erlaubt schnelle Erstellung DDS-fähiger Applikationen mit minimalem Coding: Topics und Domain Participants in XML definieren, einfaches Lua Script hinzufügen, und Sie sind in Minuten auf einer DDS Domain up and running. (Siehe Gianpieros Blog Post zu Prototyper.)

Jenen Abend schrieb ich ein Lua Script, das Prototyper anweist, die komplexen DDS Topics mit Arrays von Sequenzen zu lesen und an ein flattened Topic für das LabVIEW GUI zu republizieren. Ich testete das Script offline mit zuvor aufgezeichne

[1] [2]  >