Leistungsgrenzen komplexer Embedded-Systeme überwinden

Die Leistung von Embedded-Systemen wird durch eine Vielzahl von Faktoren beeinflusst, darunter die Hardware-Architektur, das Software-Design und die Systemkonfiguration. Die Optimierung der Leistung des Systems ist eine anspruchsvolle Aufgabe, da eingebettete Systeme oft komplex sind und in Echtzeitumgebungen arbeiten. In den letzten Jahren hat sich die Visualisierung von Trace-Daten als leistungsfähiges Werkzeug zur Analyse der Leistung eingebetteter Systeme erwiesen. Bevor die Strategien zur Analyse und Verbesserung der Leistung von virtualisierten eingebetteten Systemen erörtert werden, ist es wichtig, die in dieser Evaluierung verwendeten Leistungsmetriken zu definieren. Zu den häufigsten Leistungskennzahlen gehören die CPU-Auslastung, die E/A-Latenz und die Reaktionszeit.

Dies ist der prozentuale Anteil der Zeit, in der die CPU (Kern) aktiv einen Prozess oder eine Anwendung ausführt. Eine höhere CPU-Auslastung zeigt an, dass das System härter arbeitet und kann zu einer geringeren Leistung führen. In einem virtualisierten System ist es auch wichtig, zwischen physischen und virtuellen CPUs zu unterscheiden. Eine physische CPU ist eine physische Prozessoreinheit, die in die Hardware des eingebetteten Systems integriert ist. Eine virtuelle CPU ist ein softwarebasierter Prozessor, der eine physische CPU emuliert. Er arbeitet in einer virtuellen Umgebung, die durch eine Virtualisierungsschicht über dem Host-Betriebssystem geschaffen wird. Eine virtuelle CPU kann als eine spezielle Aufgabe betrachtet werden, die auf einer physischen CPU läuft, und sie sollte vom Hypervisor effizient auf einer physischen CPU abgebildet werden, um die Arbeitslast richtig auszugleichen.

E/A-Latenz

Dies ist die Zeit, die benötigt wird, um Eingabe-/Ausgabevorgänge abzuschließen. Eine höhere E/A-Latenz kann zu einer geringeren Leistung führen, da die Wartezeit für E/A-Vorgänge länger ist. Verschiedene Arten von E/A-Geräten haben unterschiedliche Latenzzeiten, und die Virtualisierung kann diese Unterschiede noch verstärken. So haben beispielsweise einige Arten von Netzwerkadaptern eine geringere Latenz als andere, und die Virtualisierung kann die Latenz von Adaptern mit höherer Latenz erhöhen. Auch das Betriebssystem, das auf der virtuellen Maschine läuft, kann einen Einfluss auf die E/A-Latenz haben. Einige Betriebssysteme sind für die Virtualisierung besser optimiert als andere, was sich auf den mit E/A-Vorgängen verbundenen Overhead auswirken kann. Die Eigenschaften der Arbeitslast können sich ebenfalls auf die E/A-Latenz auswirken, da einige Arbeitslasten intensiver sind als andere.

Dies ist die Zeit, die ein System benötigt, um auf eine Benutzeranforderung zu reagieren. Höhere Antwortzeiten können zu einer geringeren Benutzerzufriedenheit führen und die Benutzerfreundlichkeit des Systems beeinträchtigen. Bei virtualisierten eingebetteten Systemen ist die Reaktionszeit eine kritische Leistungskennzahl, da das System häufig in Echtzeitanwendungen wie industriellen Steuerungen, Automobilsystemen oder medizinischen Geräten eingesetzt wird. Die Reaktionszeit in diesen Anwendungen wird oft in Millisekunden oder sogar Mikrosekunden gemessen, und Verzögerungen bei der Reaktion können zu kritischen Ausfällen und Sicherheitsproblemen führen. Die Reaktionszeit in virtualisierten eingebetteten Systemen wird durch eine Vielzahl von Faktoren beeinflusst, wie z. B. die für die virtualisierten Instanzen verfügbaren Hardwareressourcen, die verwendete Virtualisierungstechnologie, die verwendeten Algorithmen für die Planung und Ressourcenzuweisung sowie die Merkmale der Arbeitslast.

Strategien zur Leistungsoptimierung und -analyse

Die gängigste Strategie zur Optimierung der Leistung virtualisierter eingebetteter Systeme ist die Abstimmung des Hypervisors und der Systemparameter durch Anpassung der Ressourcenzuweisung, z. B. CPU-Zeit, Antwortzeit und E/A-Bandbreite. Außerdem werden mehrere Benchmarks, einschließlich CPU-gebundener, speichergebundener und E/A-gebundener Arbeitslasten, verwendet, um die Leistung des Systems unter verschiedenen Bedingungen zu bewerten. Der Zeitaufwand für das Sammeln und Analysieren von Benchmarks kann jedoch enorm sein, insbesondere wenn mehrere Gastbetriebssysteme auf einem Hypervisor laufen. Andererseits könnte eine Methodik, die auf der Erfassung und intuitiven Darstellung von System-Trace-Daten während der Ausführung basiert und die Systemaufrufe, Interrupts und andere Ereignisse umfasst, viel Zeit für die Analyse der Leistungsmetriken in einem virtualisierten eingebetteten System sparen.

Es gibt verschiedene Arten von Trace-Daten, die von eingebetteten Systemen gesammelt werden können, darunter Ausführungs-Traces, Daten-Traces und Kontrollfluss-Traces. Ausführungs-Traces zeichnen die Abfolge der vom System ausgeführten Anweisungen auf, während Daten-Traces die Werte der vom System verwendeten Variablen und Datenstrukturen aufzeichnen. Kontrollfluss-Traces zeichnen die Abfolge der vom System aufgerufenen Funktionen und deren Parameter auf.

Jede Art von Trace-Daten gibt unterschiedliche Einblicke in das Verhalten des Systems. Es gibt zwei Hauptansätze für die Erfassung von Trace-Daten aus eingebetteten Systemen: hardwarebasierte und softwarebasierte. Bei hardwarebasierten Ansätzen wird dem System in der Regel Trace-Hardware hinzugefügt, wie z.B. ein Trace-Buffer oder ein Logikanalysator. Diese Hardware-Komponenten können Trace-Daten in Echtzeit und mit minimalen Auswirkungen auf die Systemleistung erfassen. Bei softwarebasierten Ansätzen wird die Software des Systems modifiziert, um Trace-Anweisungen oder Instrumentierungscode einzubauen. Diese Ansätze sind flexibler als hardwarebasierte Ansätze, können aber die Systemleistung beeinträchtigen und erfordern zusätzlichen Speicherplatz.

Das Sammeln von Trace-Daten aus eingebetteten Systemen kann aufgrund verschiedener Faktoren eine Herausforderung darstellen. Eine der größten Herausforderungen ist die Ressourcenbeschränkung von eingebetteten Systemen. Trace-Daten können erhebliche Mengen an Speicher und Verarbeitungsleistung verbrauchen, was die Systemleistung beeinträchtigen kann. Auch Echtzeitanforderungen stellen eine Herausforderung dar, da Trace-Daten gesammelt werden müssen, ohne das Timing des Systems zu stören. Daher ist es notwendig, die richtige Methode zu wählen, die von den Ressourcen des SoCs abhängt, ohne dabei die Leistung des Systems selbst zu beeinträchtigen, was in diesem Fall zu schlechten Designentscheidungen führen könnte.

Die Verwendung eines Tools zur Analyse von Trace-Daten ermöglicht einen vollständigen und intuitiven Blick auf das System. Integrierte Debugging- und Profiling-Tools, die virtualisierte Betriebssysteme und den Hypervisor unterstützen, liefern ein vollständiges Bild des Systems, das es Ingenieuren ermöglicht, kritische Teile zu messen und korrekte Software-Design-Entscheidungen zu treffen, wie in Bild 1 dargestellt.

Durch die Identifizierung von "Löchern" im Ausführungsfluss der verschiedenen Aufgaben im System und der verschiedenen Ereignisse können Engpässe ermittelt werden. Typischerweise gibt es in einem virtualisierten eingebetteten System mehrere Peripheriegeräte, die verschiedene E/A-Operationen durchführen und Unterbrechungsanforderungen erzeugen. Die Anzeige der zeitlichen Kadenz gerätespezifischer Interrupts und die Messung der Dauer einer ISR (Interrupt Service Routine) liefern wichtige Informationen über das Verhalten und die Verwaltung von I/O-Geräten und ermöglichen es, die Latenz von I/O-Operationen intuitiv und schnell zu messen. Schließlich bietet eine moderne Entwicklungsumgebung, wie die MULTI IDE von Green Hills Software, die Möglichkeit, benutzerdefinierte Ereignisse in die Trace-Daten einzufügen. Mit minimaler Code-Instrumentierung durch den Compiler und dem Hinzufügen spezifischer APIs im Hypervisor ist es möglich, benutzerdefinierte Ereignisse zu erstellen und die Reaktionszeit von Echtzeit-Tasks und Gastbetriebssystemen zu messen.

Digitales Automotive-Cockpit

Ein digitales Cockpit mit konsolidiertem Kombiinstrument und In-Vehicle Infotainment (IVI) bezieht sich auf ein modernisiertes System im Armaturenbrett eines Fahrzeugs, das verschiedene Anzeigen und Bedienelemente in einer einzigen Einheit integriert. Dieses System verwendet ein Linux- oder Android-Gastbetriebssystem, das auf einem separaten Kernel läuft. Der Zugriff erfolgt in der Regel über eine Touchscreen-Schnittstelle oder Sprachbefehle und kann in verschiedene Anwendungen und Dienste wie Apple CarPlay und Android Auto integriert werden. Die Leistungsanalyse dieser Art von Systemen ist eine sehr mühsame Aufgabe. Mit den herkömmlichen Methoden (z.B. Benchmarking des Gastbetriebssystems und Vergleich der Ergebnisse mit der nativen Ausführung) lässt sich das tatsächliche Verhalten der verschiedenen Anwendungen nur sehr schwer vorhersagen, da die Möglichkeit von Interferenzen zwischen ihnen aufgrund des gleichzeitigen Zugriffs auf Ressourcen ein sehr hohes Maß an Komplexität mit sich bringt. Bild 2 zeigt die Trace-Daten eines solchen Systems in einem leicht zu interpretierenden Format. Oben rechts sind alle physischen Kerne aufgelistet, während unten die Namen aller auf dem System laufenden Softwaremodule zu sehen sind, einschließlich Tasks (native und Gastbetriebssystem-Tasks), Interrupts und Systemereignisse. Oben links ist zu sehen, wie die Tasks auf den verschiedenen Kernen eingeplant sind, während unten zu sehen ist, wie sich das Diagramm des Aufrufstapels mit der Zeit für jede Task ändert. Dies gibt einen vollständigen Überblick über das eingebettete virtualisierte System, auch in Bezug auf die Ausführungszeit der Funktionen.  

Als zweites Beispiel dient eine große Produktionsanlage, die auf Roboterarme angewiesen ist. In diesem Szenario kann die Virtualisierung eingesetzt werden, um verschiedene Herausforderungen zu bewältigen und die Gesamteffizienz und Flexibilität des Systems zu verbessern. Industrielle Maschinen benötigen oft spezielle Hardwareressourcen, um bestimmte Funktionen auszuführen. Mit einem separaten Microkernel, der als Hypervisor fungiert, können mehrere virtuelle Maschinen auf einer einzigen physischen Maschine erstellt werden, was eine Konsolidierung der Hardware ermöglicht. Dies bedeutet, dass anstelle von separaten physischen Maschinen für jede Funktion ein Fach- oder Gastbetriebssystem verwendet werden kann, um verschiedene Aufgaben gleichzeitig auszuführen, wodurch die Ressourcennutzung optimiert und die Hardwarekosten gesenkt werden. Ein Beispiel für diese Software-Architektur ist in Bild 3 dargestellt. Die Visualisierung von Trace-Daten im Zusammenhang mit diesem SCADA-System (Supervisory Control and Data Acquisition) umfasst die visuelle Darstellung und Analyse von Daten, die von den Operationen und Prozessen des industriellen Steuerungssystems gesammelt wurden. Sie ermöglicht es Betreibern, Ingenieuren und Interessengruppen, Einblicke zu gewinnen, die Leistung zu überwachen und zu verbessern, Anomalien zu erkennen und fundierte Entscheidungen zu treffen, um die Effizienz und Zuverlässigkeit des Systems zu optimieren.

Unter Verwendung der oben beschriebenen Techniken und Prinzipien vereinfacht die visuelle Darstellung der Trace-Daten die komplexen Informationen und ermöglicht eine schnellere und effektivere Überwachung, Analyse und Reaktion auf industrielle Prozesse und Anlagen. (na)