Performance von Echtzeit-Betriebssystemen richtig messen

Embedded Systeme müssen in einem strengen Korsett an Speicher- und Prozessorressourcen arbeiten - vor allem dann, wenn echtzeitkritische Leistung gefragt ist. Wie lässt sich aber die tatsächliche Performance des eingesetzten RTOS effizient und genau bestimmen?

Anbieter zum Thema

Parasoft® Deutschland GmbH

RTI Real-Time Innovations

Desktop- bzw. Laptop-Rechner sind extrem leistungsstark und dennoch erstaunlich kostengünstig. Bei der Entwicklung von Software für Desktop-Systeme wird deshalb oft davon ausgegangen, dass uneingeschränkte CPU-Leistung zur Verfügung steht; darüber wird die Ausführgeschwindigkeit der Programme vernachlässigt. Das gilt ebenso für die verfügbaren Speicherressourcen - auch dem Umfang der Programmcodes wird wenig Aufmerksamkeit geschenkt.

Bei Embedded Systemen gelten andere Maßstäbe. Sie haben meist ausreichend CPU-Leistung, um ihre Aufgaben auszuführen - aber nicht darüber hinaus. Der verfügbare Speicher ist begrenzt. Er ist nicht unverhältnismäßig klein bemessen, lässt sich aber meist nicht erweitern. Die Energieaufnahme ist fast immer ein zentrales Thema, und Umfang und Effizienz der Software wirken sich massiv auf den Stromverbrauch eines Embedded-Gerätes aus. Aus diesem Grund ist unbedingt darauf zu achten, dass das RTOS in einem Embedded-System möglichst wenig Speicherkapazität beansprucht und die CPU möglichst effizient nutzt.

Bildergalerie

Bezüglich Performance und Speichernutzung eines RTOS gibt es drei kritische Aspekte:

• 1. Speicher – Wie viel ROM und RAM benötigt der Kernel? Welchen Einfluss haben Zusatzfunktionen und die Konfiguration?

• 2. Latenzzeit – Bezeichnet allgemein die zeitliche Verzögerung zwischen dem Auftreten eines Ereignisses und der Reaktion auf dieses Ereignis. Dieser Begriff wird gerne missverständlich verwendet, doch im Grunde genommen sind zwei Latenzzeiten ausschlaggebend, nämlich bezüglich Interrupt-Reaktion und Task-Scheduling.

• 3. Performance der Kernel-Services: Wie lange dauert es, um bestimmte Aktionen auszuführen?

Auf diese Messungen wird nachfolgend eingegangen. Leider liegt dem keine wirkliche Standardisierung zugrunde, und das ist problematisch. Das Embedded Microprocessor Benchmark Consortium würde sich zwar prinzipiell anbieten. Es ist jedoch nicht großflächig in Verwendung und ohnehin eher auf CPU-Benchmarks ausgerichtet.

RTOS-Metrik – Speichergröße

Da bei Embedded-Systemen die verfügbaren Speicherressourcen mehr oder weniger eingeschränkt sind, muss der Entwickler die RTOS-Anforderungen im Zusammenhang mit der eingesetzten CPU verstehen. Ein Betriebssystem verwendet sowohl den ROM als auch RAM.

Im ROM, meist ein Flash-Speicher, wird der Kernel-Code zusammen mit dem Code für die Laufzeitbibliothek und Middleware-Komponenten gespeichert. Dieser Code bzw. Teile davon können beim Bootvorgang in den RAM kopiert werden, da dies in manchen Fällen die Performance verbessert. Manche Daten werden auch nur gelesen. Bei statischer Kernel-Konfiguration enthalten sie umfangreiche Informationen zu den Kernel-Objekten. Die meisten Kernels sind heute jedoch dynamisch konfiguriert.

Speicherplatz im RAM wird für Kerneldatenstrukturen sowie Informationen zu den Kernelobjekten benötigt, je nachdem, ob der Kernel statisch oder dynamisch konfiguriert ist. Zudem werden etliche globale Variablen gespeichert. Auch Programmcode, der aus dem Flash in den RAM kopiert wird, beansprucht Speicherplatz.

Die Speicheranforderungen eines RTOS werden von mehreren Faktoren beeinflusst. Ausschlaggebend ist die CPU-Architektur. Die Anzahl der Befehle ist von Prozessor zu Prozessor oft sehr unterschiedlich. Angaben zu den Speicherressourcen einer bestimmten CPU geben daher noch lange keinen Aufschluss über die einer anderen CPU, selbst wenn diese aus derselben Produktreihe kommt.

Die meisten Embedded-Compiler haben zahlreiche Optimierungsmöglichkeiten. Damit lässt sich die Codegröße verringern, was aber ziemlich sicher die Performance beeinträchtigt. Optimierungen beeinflussen auch den Verbrauch an ROM-Ressourcen – aber auch den RAM-Verbrauch, wenn der Code kopiert wird. Auch die Datengröße lässt sich optimieren, da sich Datenstrukturen packen bzw. entpacken lassen. Dies hat ebenso Auswirkungen auf ROM und RAM; das Packen von Daten beeinträchtigt aber die Performance.

Für die meisten RTOS-Produkte gibt es optionale Zusatzkomponenten, deren Einsatz sich natürlich massiv auf den Speicherverbrauch auswirkt. Die meisten RTOS-Kernels sind skalierbar; im Idealfall beinhaltet das Speicherimage also nur den Programmcode, der die benötigten Funktionen unterstützt. Bei manchen RTOS ist nur der Kernel skalierbar, bei anderen dagegen auch die restliche Middleware.

Bezüglich der Skalierbarkeit gibt es unterschiedliche Auffassungen. Feingranular skalierbar bedeutet, dass nur der Core des RTOS (Scheduler etc.) und der Code für tatsächlich verwendete Serviceaufrufe im finalen Speicherimage enthalten sind und kein redundanter Code.

Auch wenn vom RTOS-Anbieter Daten zum Speicherverbrauch vorliegen, sind eigene Messungen sinnvoll, um festzustellen, ob sich das RTOS für die jeweilige Anwendung eignet. Solche Messungen sind nicht schwierig. Normalerweise liefert die vom Linker erzeugte Mapdatei die nötigen Angaben zur Speichernutzung. Je nach Linker werden verschiedene Mapdateien mit unterschiedlich vielen Informationen in verschiedenen Formaten erzeugt – von massenweise Hexadezimalzahlen bis hin zum interaktiven HTML-Dokument und allem anderen dazwischen. Es gibt auch Spezialtools, die Daten zur Speichernutzung aus ausführbaren Dateien extrahieren, z.B. objdump.

Ein Entwickler muss sich dessen bewusst sein, dass die Speichernutzung durch ein RTOS eine extrem wichtige Rolle spielt, denn nicht immer sind die Auswirkungen offensichtlich. Wie schon beschrieben, ist bei Embedded-Systemen der Speicher immer ein kritischer Faktor, doch die Prioritäten sind je nach System anders gewichtet. So hat z.B. ein kleines System vielleicht nur begrenzten On-Chip-Speicher, der natürlich Platz für den Applikationscode bieten muss. Daher sollte das RTOS möglichst klein sein.

Bei einem größeren System ist der verfügbare Gesamtspeicherplatz vielleicht weniger kritisch; stattdessen hat die Systemleistung hier einen höheren Stellenwert. Vom RTOS wird also maximale Performance erwartet; es kann also vorteilhaft sein, den Code im On-Chip-Speicher oder Cache unterzubringen. Beides lässt sich am besten umsetzen, wenn die Kernelgröße möglichst gering ist. Wenn das System Code aus dem Flash in den RAM kopiert, ist es umso wichtiger, die Anforderungen hinsichtlich der Speichernutzung zu verstehen.

(ID:45139152)