Professional Articles

Echtzeit-Leistung für Multi-Core-Designs

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.

Im Desktop-Bereich sind Single-Core-Prozessoren schon seit langem durch Multi-Core-CPUs abgelöst worden, und das Gleiche hat sich mittlerweile auch in großen Bereichen des Embedded Computing durchgesetzt. Zu groß sind die Vorteile hinsichtlich des Preis/Leistungs-Verhältnisses. In der Folge nimmt die Verfügbarkeit von leistungsstarken Embedded-CPUs mit nur einem Core im laufe der Zeit merklich ab. Das betrifft jetzt insbesondere den Bereich der funktionalen Sicherheit, 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 bekanntem Verhalten des Schedulers eine
solche maximale Laufzeit (WCET, Werst 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 kommt eine Kombination von statischer Code-Analyse und dynamischer Laufzeit-Analyse zum Einsatz.

Interferenzen: Unberechenbare Effekte

Im Falle von mehreren Kernen auf einem Prozessor zeigt sich jedoch, dass es signifikante Interferenzen zwischen der Ausführung auf den verschiedenen Cores gibt. Ursache hierfür kann sowohl die Hardware als auch die Software sein, 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 etwa PikeOS für Multi-Core-Plattformen seit 2013 gemäß EN50128 auf SIL4 für Bahnanwendungen zertifiziert, während man im Avionik-Bereich bislang alle Cores einer Multi-Core-Plattform bis auf einen aktiven deaktiviert hat. Allerdings zeichnen sich gerade in der Luftfahrt Änderungen
ab. Tatsächlich hat eine Gruppe von Zertifikations-Experten (CAST: Certification Authorities Software Team) ein Positionspapier [1] veröffentlicht, in dem sie die Bedingungen für eine echte Multi-Core-Unterstützung dargelegt hat.

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. Systemaufrufe sind dabei als kritisch zu betrachten, vor allem 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 Systemaufrufen ergeben sich jedoch Nachteile hinsichtlich der Skalierbarkeit.

Granulares Locking für mehr Leistung

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


Bild 1: Systemweite Sperren verursachen einen Overhead, der umso stärker wird, je mehr Cores das System hat

Bild 1 zeigt das Verhalten bei der Benutzung eines zentralen Lacks. 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. Daher blockiert ein Spinlock aktiv den KB. Erst nach der Freigabe durch KA kann CL gelöst werden und KB somit den eigentlichen Syscall ausführen. Man erkennt deutlich eine Verlängerung der Laufzeit für die auf dem zweiten Kern laufende Anwendung. 


Bild 2: Symmetrische Situation durch reccourcen-spezifische Locks

Bild 2 zeigt das Verhalten bei mehreren, fine grained Lacks. Der Ablauf ist im Wesentlichen der gleiche. Der Kernel fordert jedoch unterschiedliche Sperren an. KB muss in diesem Szenario daher nicht auf die Freigabe eines zentralen Lacks warten; die Situation ist also weitgehend symmetrisch. Der Effekt würde sich durch die Hinzunahme weiterer Cores signifikant verstärken, das heißt, 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 fine grained Locking dazu kommen kann, dass mehrere Cores die gleiche Sperre anfordern. Dies kann der Systemintegrator jedoch im Detail über die Konfiguration abstimmen. 

Eine ähnliche Entwicklung hat in der Vergangenheit das Betriebssystem Linux erfahren, siehe dazu die Historie zur Entfernung des »Big Kernel Lacks« [2]. 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, das heißt, 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 Entfernen des zentralen Spinlocks auch eine Steigerung der Leistung, da nun keine Prozessorzeit mehr für aktives Warten nötig ist 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. Durch das Hypervisor-Konzept ist es möglich, dass auf einer Maschine mehrere Applikationen ausgeführt werden können. Dabei sind 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 um ein komplexes Betriebssystem mit eigenständigem Dateisystem.

Beim Start des Betriebssystems steuern Konfigurationsdateien, 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-lnitialization-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, das zur Laufzeit von einer Komponente des PikeOS-Betriebssystems eingelesen und verarbeitet wird. Die Binärform wurde gewählt, weil diese ressourcensparender ist und keine aufwändige Zertifizierung eines XML-Parsers benötigt. Im Rahmen einer Zertifizierung ist jedoch die Korrektheit der
Binärdateien nachzuweisen. 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, Part 1, Supplement 5 und Part 2, Supplement 4 (Dezember 2019),
  • neues BSP: i.MX 8 BSP,
  • Unterstützung des ARMv8 Generic Interrupt Controller (GI() v 3.

Die SYSGO-eigene Linux-Distribution »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 v 8.3,
  • binutils v 2.31,
  • Linux Kernel 4.19 mit Real-Time Extensions,
  • Standard library glibc v 2.2,
  • die Host-Tools unterstützen 64 bit 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 lässt sich jetzt per Projekt einstellen,
  • 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,
  • GIHeam-Support ist standardmäßig enthalten
  • der PikeOS-Monitor zeigt Informationen über Shared-Memories an,
  • Shared-Memories werden auf einem PikeOS-Target automatisch erkannt,
  • neuer Drag & Drop-View.

»Ready for Take-off«

Die Version 5.0 hat 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.

Hinsichtlich der 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 hat sich 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.

Get connected with SYSGO


Contact us