Echtzeit-Leistung für Multi-Core-Designs

May 20, 2020

In Multi-Core-Systemen ist kaum vorhersagbar, wie sich die Kerne gegenseitig beeinflussen, wenn auf gemeinsame Ressourcen zugegriffen wird. Bisher wurde sicherheitshalber das gesamte System gesperrt, solange kritische Codesegmente ausgeführt werden. Aber das muss nicht sein, denn das geht auf Kosten des Echtzeitverhaltens.

Schon seit langer Zeit sind im Desktop-Bereich Single-Core Prozessoren durch Multi-Core CPUs abgelöst worden. Das Gleiche hat sich mittlerweile auch in großen Bereichen des Embedded Computing durchgesetzt. Hinsichtlich des Preis/Leistungs-Verhältnisses sind die Vorteile dabei signifikant. In Folge dessen nimmt die Verfügbarkeit von leistungsstarken Embedded CPUs mit nur einem Core merklich ab. Das spiegelt sich insbesondere im Bereich der funktionalen Sicherheit wider, in dem bisher eher konventionell auf Prozessoren mit nur einem Kern gesetzt wird.

Sicherheitsrelevante Systeme sind in großem Maße vom Determinismus der Ausführung von Algorithmen abhängig. Das betrifft nicht nur das Ergebnis der Berechnung, sondern auch den zeitlichen Rahmen. Es muss möglich sein, eine maximale Laufzeit anzugeben, in deren Rahmen die Ausführung garantiert abgeschlossen ist. Dies ist das wichtigste Kriterium der Echtzeitfähigkeit. Auf Prozessoren mit nur einem Kern kann bei bekannten Verhalten des Schedulers eine solche maximale Laufzeit (WCET (worst case execution time)) bestimmt werden. Eine Komplikation stellt der Einfluss von Interrupts dar, daher werden diese meist - zumindest während der Ausführung von kritischem Code - unterdrückt. Weitere Einflüsse haben Caches sowie das Verhalten von Memory Controllern. Im Allgemeinen ist die Berechnung der WCET mit Hilfe von Analyse Tools jedoch lösbar. Oft wird eine Kombination von statischer Code-Analyse und dynamischer Laufzeit-Analyse eingesetzt.

Im Falle von mehreren Kernen auf einen Prozessor zeigt sich jedoch, dass es signifikante Interferenzen zwischen der Ausführung auf den verschiedenen Cores gibt. Diese können sowohl von der Hardware als auch der Software verursacht werden, und dabei kann die Ausführung von kritischem Code durch eine auf einem anderen Core ausgeführte Software erheblich verlangsamt werden. Eine Bestimmung der WCET wird unmöglich oder muss mit derart großen Sicherheitsmargen angegeben werden, dass die Vorteile eines Multi-Core Systems nicht mehr ausgespielt werden können. Auf diese Situation haben verschiedene Branchen unterschiedlich reagiert. So ist z.B. PikeOS für Multi-Core Plattformen seit 2013 gemäß EN 50128 auf SIL 4 für Bahnanwendungen zertifiziert, während im Avionik Bereich bislang alle Cores einer MCP bis auf einen aktiven deaktiviert wurden. Allerdings zeichnen sich gerade in der Luftfahrt Änderungen ab. Tatsächlich hat eine Gruppe von Zertifikations-Experten (CAST: Certification Authorities Software Team) ein Positionspapier veröffentlicht, in dem die Bedingungen für eine echte Multi-Core Unterstützung dargelegt werden. 1

Eine zentrale Rolle für das Verhalten eines Multi-Core Systems spielt das Betriebssystem. Mit dem flexiblen Time Partition Management von PikeOS lässt sich präzise festlegen, zu welchem Zeitpunkt und wie lange eine Applikation auf welchem Core ausgeführt wird. Damit ist jedoch nicht garantiert, dass die entsprechenden Algorithmen auch innerhalb ihres Zeitfensters abgeschlossen werden können. Dabei sind Systemaufrufe als kritisch zu betrachten, insbesondere wenn sie zeitgleich auf mehreren Cores erfolgen. Insbesondere ist zu berücksichtigen, dass Ressourcen gegen konkurrierenden Zugriff zu schützen sind. Üblicherweise wird dazu während eines Systemaufrufs im Kernel-Space ein zentraler Lock aktiviert, sodass die Ausführung während des kritischen Pfades nur auf einem Core möglich ist. Alle anderen Cores müssen in dieser Situation aktiv warten (Spinlock). Dieses Design hat den Vorteil einer einfachen und klaren Implementierung. Bei starker Auslastung durch die vermehrte Benutzung von System Calls ergeben sich jedoch Nachteile hinsichtlich der Skalierbarkeit.

Granulares Locking für mehr Performance

PikeOS 5 setzt deshalb nicht auf einen zentralen Lock, sondern ersetzt diesen durch mehrere Ressourcen-spezifische Locks (fine grained locking). Damit generieren Partitionen, die keine Ressourcen teilen, auch keine Konflikte. Zudem sind die durch Locks geschützten Code-Abschnitte erheblich in ihrer Länge reduziert worden.

Abbildung 1: Systemweite Sperren verursachen einen Overhead, der umso größer ist, je mehr Kerne das System hat

Abbildung 1 zeigt das Verhalten bei der Benutzung eines zentralen Locks. Anwendung A, laufend auf dem ersten Core, sendet einen SYSCALL_A an den Kernel. Anschließend wird der Kernelspace KA betreten und dort der zentrale Lock CL angefordert. Da dieser momentan frei ist, antwortet CL sofort und der System Call kann im Kontext des Kernels ausgeführt werden. Anschließend wird der Lock freigegeben und die Anwendung kann über die (erfolgreiche) Ausführung benachrichtigt werden. In diesem Beispiel läuft Anwendung B auf einem zweiten Core und sendet nur kurz nach Anwendung A den SYSCALL_B. Auch hier wird in den Kernelspace gewechselt und der Lock CL angefordert. Allerdings ist dieser noch gesperrt und daher wird KB aktiv durch einen Spinlock blockiert. Erst nach der Freigabe durch KA kann CL gelöst werden und somit KB den eigentlichen Syscall ausführen. Man erkennt deutlich eine Verlängerung der Laufzeit für die auf dem zweiten Kern laufende Anwendung.

Abbildung 2: Symmetrische Situation aufgrund von ressourcenspezifischen Sperren

Abbildung 2 zeigt das Verhalten bei mehreren, fine grained Locks. Im Wesentlichen ist der Ablauf der Gleiche. Es werden vom Kernel jedoch unterschiedliche Sperren angefordert. Daher muss in diesem Szenario KB nicht auf die Freigabe eines zentralen Locks warten. Die Situation ist daher weitgehend symmetrisch. Der Effekt würde sich durch die Hinzunahme weiterer Cores signifikant verstärken, d.h. ein System mit einem zentralen Lock skaliert nur sehr schlecht.

Es sei allerdings ausdrücklich darauf hingewiesen, dass es im Falle von explizit zwischen Partitionen geteilten Ressourcen auch beim Einsatz von von fine grained Locking dazu kommen kann, dass von mehreren Cores die gleiche Sperre angefordert wird. Dies kann jedoch vom Systemintegrator im Detail über die Konfiguration abgestimmt werden.

Eine ähnliche Entwicklung hat in der Vergangenheit das Betriebssystem Linux erfahren, siehe dazu die Historie zu Entfernung des Big Kernel Locks2. Dabei ist jedoch zu beachten, dass es sich bei PikeOS um einen Micro-Kernel handelt, dessen Codebasis um ein Vielfaches kleiner ist. Zum anderen wurde in PikeOS das Konzept der Partitionierung auch direkt im Kernel-Design berücksichtigt, d.h. Teile des Kernel-Speichers sind exklusiv bestimmten Partitionen zugeordnet und die Ressourcen sind strikt nach Partitionen und Tasks im Speicher abgelegt. Dies erleichterte die Festlegung der lokalen Sperren.

Neben der Verringerung der WCET ergibt sich durch die Entfernung des zentralen Spinlocks auch eine Steigerung der Performance, da nun keine Prozessorzeit mehr für aktives Warten benötigt wird und somit direkt der Applikation zur Verfügung steht.

Beschleunigte Zertifizierung durch Tool Qualifikation

Eine weitere bedeutende Neuerung in PikeOS 5.0 betrifft das Build-System und den Aufwand bei der Zertifizierung eines komplexen Systems. Dank des Hypervisor-Konzeptes können auf einer Maschine mehrere Applikationen ausgeführt werden. Dabei werden die Applikationen strikt voneinander isoliert durch Ressource- und Time-Partition-Mechanismen. Dedizierte Kommunikationskanäle sind jedoch möglich. Alle Applikationen liegen getrennt voneinander als komplett eigenständige Dateien vor. Dabei kann es sich bei einer Applikation sowohl um eine einzelne, von PikeOS nativ ausführbare Binärdatei handeln als auch ein komplexes Betriebssystem mit eigenständigem Filesystem. Beim Start des Betriebssystem wird über Konfigurationsdateien gesteuert, in welcher Partition eine Applikation ausgeführt wird, welche Ressourcen zu Verfügung stehen und auf welche Dateien und Dateisystem sie Zugriff hat.

Dabei stehen dem Systemintegrator zwei Konfigurationsdateien zu Verfügung:

1. Die Virtual Machine Initialization Table (VMIT): Konfiguration aller Partitionen, Zugriffsrechte auf Ressourcen und Kommunikationskanäle

2. ROM File System Konfiguration (RBX): Konfiguration aller (ausführbaren) Dateien, die in das ROM File System aufgenommen werden sollen

Beide Konfigurationsdateien liegen im XML-Format vor. Diese Dateien werden durch den VMIT Compiler und ROM Image Builder in ein Binärformat übersetzt, welches zur Laufzeit von einer Komponente des PikeOS Betriebssystem eingelesen und verarbeitet wird. Die Binärform wurde gewählt, weil diese zunächst ressourcensparender ist und zudem keine aufwändige Zertifizierung eines XML-Parsers benötigt. Im Rahmen einer Zertifizierung muss jedoch die Korrektheit der Binärdateien nachgewiesen werden. Dies geschah bislang in einem aufwendigen Verfahren unter der Zuhilfenahme weiterer Tools.

Jede Änderung an einer XML-Datei erzwingt zudem eine Wiederholung des Verfahrens. Mit dem Release von PikeOS 5.0 sind jedoch sowohl VMIT Compiler als auch ROM Image Builder als voll qualifizierte Tools verfügbar. Der Nachweis der Korrektheit kann daher direkt auf der Grundlage der originären XML Dateien erfolgen. Damit wird der Workflow bei der Zertifizierung erheblich beschleunigt.

Weitere Verbesserungen

Mit der Freigabe von PikeOS 5.0 kommen zudem die folgenden Neuerungen:

Verringerung der Zugriffszeit auf Kernel-Treiber
Alle Treiberklassen sind auch im Kernel-Space verfügbar
Unterstützung für Dateisysteme im Kernel-Space
Verfügbarkeit eines DAL-B Certification Kits für PowerPC
Partition Callback Hooks bieten die Möglichkeit, Error Counters zu implementieren und somit Security Auditing zu realisieren
Das APEX API ist konform zu dem neuen Stand des Standards ARINC653, Part1 Supplement 5 und Part2 Supplement 4, (Dezember 2019)
Neues BSP: i.MX 8 BSP
Unterstützung des ARMv8 Generic Interrupt Controller (GIC) v3

Die SYSGO eigene Linux Distribution genannt „ELinOS“ wird von vielen Kunden als Linux Partition direkt auf PikeOS verwendet. Die folgenden Änderungen stehen in ELinOS Version 7 für PikeOS zur Verfügung:

Toolchain gcc v8.3
binutils v2.31
Linux Kernel 4.19 mit Real-Time Extensions
Standard library glibc v2.2
Die Host tools unterstützen 64bit nativ auf Windows und Linux

Die für PikeOS und ELinOS notwendige Entwicklungsumgebung „CODEO“ in der Version 7 bietet nun einige Änderungen, die es dem Anwender leichter machen, Projektkonfigurationen durchzuführen:

Vereinfachte Erstellung des ROM-File Systems.
Die Konfiguration der Validation kann jetzt per Projekt eingestellt werden
Die ROM Struktur des PikeOS Boot Files kann angezeigt werden.
Die Struktur einer binären Virtual Machine Initialization Table kann in der XML Darstellung angezeigt werden.
GIT Team Support ist standardmäßig inkludiert
Der PikeOS Monitor zeigt Informationen über Shared-Memories an.
Shared-Memories werden auf einem PikeOS Target automatisch erkannt.
Neuer Drag & Drop View

Zusammenfassung

Mit der Version 5.0 wurde die Leistung und Skalierbarkeit von PikeOS 5.0 signifikant erhöht. So wurde die Zugriffszeit auf Kernel-Treiber beschleunigt und das System durch die Einführung von fine grained Locks wesentlich skalierbarer hinsichtlich Multi-Core Architekturen. Weiterhin sind jetzt alle Treiberklassen sowie Dateisysteme im Kernel verfügbar.

In Hinsicht auf die Zertifizierbarkeit ist PikeOS 5.0 konform mit dem CAST-32A Positionspapier und damit bereit für den Einsatz von Mehrkernprozessoren in der Luftfahrt. Durch die Qualifikation der Konfigurationstools wird die Zulassung komplexer Systeme vereinfacht und beschleunigt. Für die PowerPC Architektur ist ein erstes Certification Kit für DAL-B verfügbar. Weitere Architekturen sowie weitere Certification Kits gemäß IEC 61508, ISO 26262 und EN 50128 sollen in Kürze folgen.

Professional Articles