Der traditionelle Ansatz zur Bereitstellung einer größeren Verarbeitungsbandbreite bestand darin, die CPU-Taktfrequenz zu erhöhen, die pseudoparallele Verarbeitung auf Befehlsebene durch Befehlspipelines und spekulative Programmausführungen zu steigern sowie die Cache-Größe und die Anzahl der Cache-Ebenen zu erhöhen. Beim heutigen Stand der Technik ist dieser Ansatz an seine Grenzen gestoßen. Die Erhöhung der CPU-Frequenz führt zu einem unverhältnismäßig hohen Stromverbrauch und Wärmeverlust und wirft immer mehr Probleme aufgrund von chipinternem und -externem Übersprechen, Signalverzögerungen und Reflexionen auf. Bestehende Parallelität und Abhängigkeiten auf Code-Ebene verhindern eine weitere Leistungssteigerung durch parallele Ausführung auf Befehlsebene. Um die Prozessorleistung weiter zu steigern, ist die Chipindustrie dazu übergegangen, Hochleistungsprozessoren mit mehreren Kernen zu entwickeln. 

Die Entwicklung von IMA-Hochleistungsplattformen auf Multicore-Basis wird ein notwendiger Schritt sein, um eine Integration auf Funktionsebene in größerem Umfang zu erreichen. Die Frage lautet: "Kann eine auf mehreren Kernen basierende Plattform das gleiche Maß an Determinismus erreichen wie eine Plattform mit einem Kern und kann dies nachgewiesen werden?"

Dieses Papier befasst sich mit Zertifizierungsaspekten von IMA-Plattformen auf Multicore-Basis, wobei der Schwerpunkt auf den heutigen Technologien und Prozessen liegt. Das Papier bietet eine Analyse potenzieller hardware- und softwarebezogener Interferenzkanäle zwischen Partitionen, die auf einer Multicore-basierten Plattform laufen. Verschiedene Kernsoftwarekonzepte, die in bestehenden Implementierungen zu finden sind, wie z.B. asymmetrisches Multi-Processing (AMP) und symmetrisches Multi-Processing (SMP), werden im Hinblick auf Partitionierungsaspekte bewertet.  

Einführung

In allen Industriebereichen werden immer mehr sicherheitsrelevante Dienste mit Hilfe elektronischer Geräte realisiert, und die Nachfrage nach Informations-, Komfort- und Unterhaltungsdiensten steigt ständig. Gleichzeitig erfordern Produkt- und Umweltauflagen eine Reduzierung von Größe, Gewicht und Stromverbrauch, was zu einem hohen Funktionsintegrationsgrad führt. Die Integration von Softwaremodulen mit unterschiedlichen Sicherheits-, Robustheits- und Qualitätsanforderungen, die von unabhängigen Teams entwickelt wurden, erfordert gut definierte Komponentenschnittstellen, Entwicklungsprozesse und eine eingebettete Plattform, die ein hohes Maß an Funktionstrennung und Fehlereindämmung unterstützt. Die Herausforderungen der Funktionsintegration haben zur Entwicklung von Standards und Rahmenwerken wie AUTOSAR für die Automobilindustrie und IMA für die Luft- und Raumfahrtindustrie geführt.

Das Hauptziel der IMA-Architektur ist die sichere Integration von Anwendungen, die für unterschiedliche Sicherheitsstufen entwickelt wurden, was eine strikte Partitionierung der Plattformressourcen erfordert. 

Zu Beginn von AUTOSAR lag das Hauptaugenmerk auf der Senkung der Entwicklungs- und Wartungskosten durch standardisierte und austauschbare Softwarekomponenten, um den Wettbewerb zwischen Softwareanbietern zu ermöglichen. Heute werden immer mehr sicherheitsrelevante Funktionen wie Fahrassistenz-, Crashvermeidungs- oder Crashsicherheitssysteme entwickelt. Gleichzeitig geht die Tendenz dahin, die Anzahl der Steuergeräte zu reduzieren, was ebenfalls ein Partitionierungskonzept erforderlich macht, das in AUTOSAR Release 4 behandelt wird.

Überlegungen zur Zertifizierung

Die Integration von Software-Services mit unterschiedlichen Anforderungen an Funktionalität, Robustheit, funktionaler Sicherheit (Safety) und IT-Sicherheit (Security) erfordert eine eingebettete Plattform, die 

• ausreichende CPU-Leistung, Speicherressourcen und E/A-Bandbreite bietet,
• ausreichend zuverlässig ist, 
• ein deterministisches und vorhersehbares Echtzeitverhalten aufweist,
• eine sichere Partitionierung von Ressourcen und CPU-Zeit unterstützt und
• nach den geltenden Sicherheitsstandards zertifizierbar ist.

Was sind die Hauptunterschiede bei der Zertifizierung zwischen einer Single-Core- und einer Multi-Core-basierten Plattform?

Sicheres Prozessordesign

Die heutigen IMA-Plattformen verwenden in der Regel Prozessoren wie die IBM 603, 604, 75x oder 74xx Familien. Diese Prozessoren basieren auf der RISC-Architektur und haben, mit Ausnahme des PPC 74xx, eine recht einfache Cache- und Pipeline-Architektur. Bis zu einem gewissen Grad sind Design-Dokumente verfügbar, um den Zertifizierungsprozess zu unterstützen. Aufgrund des häufigen Einsatzes in Avionikplattformen liegen viele Betriebserfahrungen vor, was das Risiko von unentdeckten systematischen Fehlern verringert. Die Zertifizierungsbehörden haben IMA-Plattformen, die auf diesem Prozessor basieren, für Anwendungen mit einer Kritikalität bis zur Stufe A akzeptiert.

Ein Multi-Core-Prozessor ist in der Regel der Nachfolger eines hochentwickelten Single-Core-Prozessors, der alle Funktionen wie komplexe Befehlspipelines, Verzweigungsvorhersage und mehrstufige Caches implementiert. Darüber hinaus benötigen sie Cache-Kohärenzmodule und Kreuzschienen zur Verbindung der Kerne untereinander. Multi-Core-Prozessoren stellen die Spitze der Chip-Technologie dar, und es ist daher sehr unwahrscheinlich, dass die Chip-Hersteller detaillierte Informationen über das Chip-Design zur Verfügung stellen, um den Plattform-Zertifizierungsprozess zu unterstützen. Ein weiterer wichtiger Punkt ist, dass Multi-Core-CPUs oft nur als System on Chip (SoC) erhältlich sind, insbesondere CPUs der PowerPC-Familie. Die Entwurfssicherheit von Mikroprozessoren basiert normalerweise auf ihrer Verwendung als COTS und der Anwendung von DO-178B mit Zieltests für die von ihnen unterstützte Software.

Bei Mikrocontrollern stellt sich die Situation anders dar. Aufgrund der Integration von Verarbeitungskomponenten und peripheren Komponenten wie Buscontrollern und Kommunikationsgeräten können Teile des Hardware-Zertifizierungsprozesses umgangen werden. Die Zertifizierungsstellen verlangen zusätzliche Nachweise dafür, dass die bei der Entwicklung digitaler Geräte angewandten Verfahren ein dem Verwendungszweck des Geräts entsprechendes Maß an Entwicklungssicherheit bieten. Das Problem ist nun, dass es nicht möglich ist, einen DO-254-konformen Zertifizierungsprozess ohne detaillierte Designdokumentation des Geräts durchzuführen. Als Alternative akzeptieren die Zertifizierungsbehörden Betriebserfahrungen in vergleichbaren Anwendungen, wenn nachgewiesen werden kann, dass keine Probleme aufgetreten sind. Unter einer vergleichbaren Anwendung ist eine avionische Anwendung zu verstehen. Dies führt zu einer Art Bootstrap-Problem. Um dieses Problem zu überwinden, müssen vielversprechende Chipkandidaten zunächst in wenig kritischen Anwendungen eingesetzt und systematisch alle Betriebsdaten und Problemberichte gesammelt werden. 

Fehlererkennung und -korrektur

Die in Avionikplattformen verwendeten Prozessoren implementieren in der Regel Fehlerkorrekturcodes (Error Correction Codes, ECC) zur Erkennung und Korrektur von Einzel- oder Mehrbitfehlern in Registern und Caches. Der PPC 750GX unterstützt den Lock-Step-Modus, der es ermöglicht, zwei oder mehr dieser Prozessoren mit einem Voter (z. B. einem 2oo3-Voter) zu verbinden, um eine Plattform aufzubauen, die extrem widerstandsfähig gegen Single Event Upset (SEU) ist.

Multi-Core-Prozessoren sind aufgrund der größeren Chipfläche und der abnehmenden Strukturgröße [1], [2] anfälliger für SEU als die in bestehenden IMA-Plattformen verwendeten Prozessoren. Bei der Auswahl eines Multicore-Prozessors für eine Avionikplattform muss ein ausreichender ECC-Schutz berücksichtigt werden. Möglicherweise muss auf Systemebene zusätzliche Redundanz implementiert werden, um die höhere Wahrscheinlichkeit von SEUs zu kompensieren.

Ressourcen- und Zeitpartitionierung

Ein- und Mehrkernprozessoren verwenden dieselben Techniken zur Unterstützung des Ressourcenschutzes, beide nutzen das Konzept der Privilegierungsebenen und bieten eine Speicherverwaltungseinheit (Memory Management Unit , MMU) zur Kontrolle des Zugriffs auf privilegierte Anweisungen und Prozessorregister, physischen Speicher und speicherabgebildete E/A-Geräte. Was die Zertifizierung der Ressourcenpartitionierung anbelangt, so gibt es keinen grundlegenden Unterschied zwischen einer Plattform mit einem und einer mit mehreren Kernen.

Die Zeitpartitionierung ist bei einem System mit mehreren Kernen komplizierter. Bei einem Single-Core-Prozessor gibt es jeweils nur einen Ausführungsstrang. Dieser Thread kann durch ein asynchrones Ereignis unterbrochen werden. In diesem Fall wird die Kontrolle an den entsprechenden Handler übergeben, aber es findet keine gleichzeitige Ausführung statt. Eine Ausnahme kann ein E/A-Gerät sein, das über DMA-Fähigkeiten (Direct Memory Access) verfügt {2}.  

Auf einem Multi-Core-Prozessor ist die parallele Ausführung der Normalfall, was zu Interferenzen zwischen Anwendungen führen kann, die auf verschiedenen Kernen laufen. Diese Interferenzkanäle werden in den folgenden Abschnitten erörtert.

Hardware-Interferenz-Kanäle

Anwendungen, die auf verschiedenen Kernen eines Mehrkernprozessors laufen, werden nicht unabhängig voneinander ausgeführt. Auch wenn es keinen expliziten Daten- oder Kontrollfluss zwischen diesen Anwendungen gibt, besteht eine Kopplung auf Plattformebene, da sie sich implizit Plattformressourcen teilen. Eine Plattformeigenschaft, die zu Störungen zwischen unabhängigen Anwendungen führen kann, wird als Hardware-Interferenzkanal bezeichnet. Die Analyse von Hardware-Interferenzkanälen erfordert ein tiefes Verständnis der Plattformarchitektur einschließlich der CPU-Interna.

Plattform-Übersicht

In diesem Papier geht es um die Aufrüstung bestehender Konzepte auf COTS-Multi-Core-Prozessoren und nicht um die Bewertung neuer Prozessor- oder Plattformarchitekturen. Daher gehen wir von einer Plattformarchitektur aus, wie sie in den heutigen IMA CPIOM-Modulen zu finden ist, und ersetzen die Single-Core-CPU durch eine Multi-Core-CPU. Die in dieser Arbeit behandelten Multi-Core-Prozessoren implementieren das Unified Memory Model, was bedeutet, dass alle Kerne denselben physikalischen Adressraum nutzen. Dies vereinfacht das Plattformdesign, da nur ein externer Prozessorbus benötigt wird und die Kommunikation zwischen den Kernen über einen gemeinsamen physischen Speicher möglich ist. Abbildung 1 zeigt die typische Architektur einer solchen Plattform.

Abbildung 1: Dual-Core-basierte CPIOM-Plattform (Core Processing & I/O Modules)

Einige der Hardware-Komponenten wie der Speicher-Controller, der PCI-Controller oder andere E/A-Geräte können zusammen mit der CPU integriert werden, um ein Multi-Prozessor-System-on-Chip (MPSoC) zu bilden. 

CPU-Kerne

Es wird davon ausgegangen, dass die CPU-Kerne für sich genommen unabhängig voneinander arbeiten, solange sie nicht auf gemeinsame Ressourcen zugreifen oder Inter Processor Interrupts (IPIs) verwenden. IPIs werden zusammen mit den softwarebezogenen Störkanälen behandelt, da sie aktiv von der Software ausgelöst werden müssen.

Caches

Zwei verschiedene Aspekte der Cache-Architektur können zu CPU-übergreifenden Interferenzkanälen führen: Cache-Kohärenz und Cache-Sharing.

Bevor wir die Interferenzkanäle untersuchen, die durch die Prozessor-Caches entstehen, geben wir einen kurzen Überblick über die grundlegende Cache-Architektur.

Das Speichersystem kann als hierarchisches System mit dem CPU-Kern an der Unterseite, gefolgt von einer oder mehreren Ebenen von Caches und dem Speicher an der Oberseite betrachtet werden. Der Cache, der direkt mit der CPU verbunden ist, ist der L1-Cache, gefolgt vom L2-Cache und so weiter. Diese höchste Cache-Ebene ist mit dem externen Bus und damit mit dem Hauptspeicher verbunden.

Eine Datenanforderung, die auf einer bestimmten Ebene nicht erfüllt werden kann, wird an die nächsthöhere Ebene delegiert. Mit zunehmender Cache-Ebene steigt die Cache-Größe, aber auch die Zugriffslatenz.

Die Daten werden zwischen den verschiedenen Ebenen des Speichersystems in Abschnitten fester Größe übertragen, die Cache-Zeilen genannt werden. Die Größe einer Cache-Zeile ist spezifisch für die Prozessorarchitektur, typische Werte sind 32 oder 64 Byte. Die Cache-Zeilen sind in Cache-Sets organisiert und ein oder mehrere Cache-Sets bilden den gesamten Level-N-Cache. Die meisten modernen Caches sind "Virtually Indexed - Physically Tagged" (VIPT), was bedeutet, dass die Cache-Zeile innerhalb eines Cache-Satzes auf der Grundlage der virtuellen Adresse bestimmt wird und die physikalische Adresse als Cache-Tag verwendet wird. Bei einer gegebenen Cache-Größe S, der Anzahl der Cache-Sets N und der Cache-Zeilengröße L wird der Cache-Index I für eine gegebene virtuelle Adresse V wie folgt berechnet:

I = (V mod (S / N)) / L

Das bedeutet, dass alle Adressen der Form V + n*(S/N), wobei n eine positive oder negative ganze Zahl ist, zum gleichen Cache-Index führen. 

Wenn ein neuer Eintrag im Cache gespeichert werden muss, werden alle Mengen nach einem ungültigen Eintrag bei dem entsprechenden Index durchsucht. Wird ein ungültiger Eintrag gefunden, wird er zur Speicherung des neuen Wertes verwendet, andernfalls wird ein vorhandener Eintrag ersetzt, was erfordern kann, dass die entsprechenden Daten zurück in den Speicher geschrieben werden, bevor der Eintrag für die neuen Daten verwendet werden kann. Der zum Ersetzen einer Cache-Zeile verwendete Algorithmus ist CPU-spezifisch. Häufig werden LRU- (Line Replaceable Units) oder Zufallsalgorithmen verwendet.

Cache Sharing

Der L1-Cache ist in der Regel in einen Daten- und einen Befehlscache unterteilt, während alle anderen Ebenen Daten und Befehle speichern. Die meisten Multi-Core-Prozessoren verfügen über einen dedizierten L1-Daten- und Befehls-Cache pro Kern, während die Architektur des L2- und L3-Cache je nach CPU-Familie variiert {3}.

Gemeinsam genutzte Caches sind eine wesentliche Ursache für Störungen in einem Multi-Core-Prozessor. Ein Vergleich des Lese- und Schreibdurchsatzes zwischen einem Intel Pentium Dual Core E5300 und einem AMD Athlon II x2 Prozessor zeigt die Auswirkungen eines gemeinsam genutzten L2-Caches. 

Der Intel-Prozessor verfügt pro Kern über einen 32 KByte + 32 KByte großen L1-Daten- und Befehls-Cache und einen gemeinsamen 2-MByte-Unified-L2-Cache.

Der AMD-Prozessor verfügt über einen 64 KByte + 64 KByte L1-Daten- und -Befehls-Cache pro Kern und einen vereinheitlichten L2-Cache von 512 KByte pro Kern.

Um die durch die gemeinsame Nutzung des Cache verursachte Interferenz zwischen zwei Kernen zu messen, lesen oder schreiben beide Kerne auf einem Datensatz fester Größe. Die Größe des Datensatzes wird von einem Wert, der klein genug ist, um in die L1-Caches beider Prozessoren zu passen, auf einen Wert erhöht, der größer ist als der L2-Cache beider Prozessoren. Die Datensätze überschneiden sich nicht, um Störungen durch Cache-Kohärenz-Effekte zu vermeiden. Der Zugriff auf die Daten erfolgt in 32-Bit-Entitäten mit einem Inkrement von 33 Wörtern, um sicherzustellen, dass nachfolgende Daten nicht aus derselben Cache-Zeile und auch nicht aus der nächsten Cache-Zeile gelesen werden, die der Prozessor möglicherweise vorher geholt hat. Zunächst wird der Datendurchsatz für Lese- und Schreibzugriffe gemessen, wenn der andere Kern inaktiv ist, und dann, wenn beide Kerne gleichzeitig lesen und schreiben.

Abbildung 2 zeigt die Ergebnisse für die beiden CPUs (beachten Sie die logarithmische Skala der y-Achse). Die Ergebnisse können wie folgt interpretiert werden:

Wenn die Datenmenge klein genug ist, um in den L1-Cache zu passen (der für jeden Kern privat ist), zeigen der Intel- und der AMD-Prozessor keine Leistungseinbußen, wenn der zweite Kern aktiv wird.

Wenn die Datenmenge kleiner ist als der L2-Cache, auf den die Kerne zugreifen können, und der L2-Cache nicht gemeinsam genutzt wird (AMD-Prozessor), verursacht der zweite Kern ebenfalls keine Leistungseinbußen.

Wenn die Datenmenge kleiner ist als der für einen Kern sichtbare L2-Cache und der L2-Cache gemeinsam genutzt wird (Intel-Prozessor), liegt der Leistungsverlust durch den zweiten Kern im schlimmsten Fall je nach Größe der Datenmenge zwischen 30 % und 95 % bei Schreiboperationen und 19 % und 92 % bei Lesezugriffen. Die größte Auswirkung (92 %) wird beobachtet, wenn der Datensatz genau die Größe des L2-Cache hat, da bei einem Kern die Daten noch vollständig in den L2-Cache passen, während bei zwei Kernen alle Daten aus dem Speicher geholt werden müssen, was bedeutet, dass wir die Leistung des L2-Cache mit der Leistung des Speicherbusses vergleichen.

Wenn die Datenmenge deutlich größer als der L2-Cache ist, beträgt der durch den zweiten Kern verursachte Leistungsverlust im schlimmsten Fall ~50 % für Lese- und Schreiboperationen.

Abbildung 2: Lese- und Schreibdurchsatz bei getrennten Datensätzen (Mbyte)

Cache-Kohärenz

Ein weiterer wichtiger Aspekt im Zusammenhang mit der Verwendung von Caches ist die Konsistenz lokaler Caches, die mit einer gemeinsamen Ressource verbunden sind. Die Cache-Kohärenz ist besonders wichtig in Multi-Core-Systemen mit einheitlichem Speicher. Cache-Kohärenz bedeutet:

Wenn einer der lokalen Caches von Kern CA einen Verweis auf eine physische Ressource Px enthält und der im Cache gespeicherte Wert aktueller ist als der in Px gespeicherte Wert, muss jeder Lesezugriff von einem beliebigen Kern (einschließlich Kern CA) den vom Kern CA im Cache gespeicherten Wert liefern.

Die Kohärenz zwischen den Caches wird mit Hilfe des Cache-Kohärenzprotokolls aufrechterhalten. Eine ausführliche Beschreibung der verschiedenen Cache-Kohärenzprotokolle ist in [3] zu finden. Das Prinzip des Cache-Kohärenzprotokolls kann anhand des MSI-Protokolls erklärt werden.

Das MSI-Protokoll definiert für jede Cache-Zeile die Zustände Modified, Shared und Invalid.

Eine modifizierte Cache-Zeile enthält Daten, die in den Cache, aber noch nicht in die Referenzressource geschrieben wurden. Nur ein Cache kann eine modifizierte Cache-Zeile für eine bestimmte Ressource haben, in allen anderen Caches muss der entsprechende Eintrag ungültig sein.

Eine gemeinsame Cache-Zeile speichert die gleichen Daten wie die Referenzressource. Mehrere Caches können eine gemeinsame Cache-Zeile haben, die auf dieselbe physische Ressource verweist.

Eine ungültige Cache-Zeile verweist auf keine physische Ressource.

Die Aktionen, die das MSI-Protokoll durchführt, um die Caches in einem konsistenten Zustand zu halten, sind in Tabelle 1 für Schreib- und Lesezyklen dargestellt. Der lokale Cache ist der Cache des aktiven Kerns, der die Schreib- oder Leseoperation durchführt, die entfernten Caches sind die Caches der anderen Kerne, die in Bezug auf den anstehenden Zugriff als passiv betrachtet werden. Die Zustandsübergänge müssen für jedes Paar von lokalen und entfernten Caches berücksichtigt werden. Die schattierten Zellen zeigen die Zustandsübergänge, die sich auf die passiven Kerne auswirken.

Tabelle 1: MSI-Zustandsübergänge für Schreib- und Lesezyklen

Ein Sonderfall der Leistungsverschlechterung aufgrund der Cache-Kohärenz ist das sogenannte False Sharing [4]. False Sharing kann auftreten, wenn zwei Kerne auf logisch unabhängigen Daten arbeiten, diese Daten aber physisch in einem Speicherbereich gespeichert sind, der in derselben Cache-Zeile landet. In diesem Fall ist der Leistungsabfall derselbe, als ob die Prozessoren auf dieselben Daten zugreifen würden.

Um die durch das Kohärenzprotokoll verursachten Störungen zu messen, verwenden wir den gleichen Aufbau wie bei der vorherigen Messung, aber jetzt arbeiten die beiden Kerne mit dem gleichen Datensatz, um Cache-Verweise auf den gleichen physischen Speicher in beiden Kernen zu erzeugen.

Wenn der Datensatz klein genug ist, macht jeder Schreibzugriff des einen Kerns den Cache-Eintrag ungültig, auf den der andere Kern als nächstes verweist. Abbildung 3 zeigt die Ergebnisse für die beiden CPUs (beachten Sie die logarithmische Skala der y-Achse). Das Ergebnis zeigt Folgendes:

Wenn beide Kerne nur lesen, verursacht der zweite Kern im Falle des Intel-Prozessors fast keine Leistungseinbußen über den gesamten Bereich der Datensätze, während beim AMD-Prozessor die Leistung auf 50 % sinkt, wenn der Datensatz größer als der L2-Cache ist.

Abbildung 3: Lese- und Schreibdurchsatz bei gemeinsam genutzten Datensätzen (Mbyte)

Wenn beide Kerne nur schreiben, leidet der Intel-Prozessor viel weniger unter dem gleichzeitigen Lesen als der AMD-Prozessor, aber die Abhängigkeit von der Größe der Datenmenge ist ähnlich.

Wenn ein Kern liest, während der andere Kern denselben Datensatz schreibt, verhalten sich Intel- und AMD-Prozessoren völlig unterschiedlich. Abbildung 4 zeigt den relativen Durchsatz für beide Prozessoren im Vergleich zum Durchsatz, wenn nur ein Kern aktiv ist. Auf dem Intel-Prozessor leidet die schreibende CPU viel weniger unter dem gleichzeitigen Lesen als auf dem AMD-Prozessor, allerdings beträgt der maximale Leistungsverlust auch für den Fall, dass die Datenmenge 4 MByte groß ist, 90 %. Auf dem AMD-Prozessor beträgt der Leistungsverlust bei kleinen Datensätzen 99 % und bewegt sich bei großen Datensätzen in Richtung 50 %. Vergleicht man den Leistungsverlust beim Lesen, so stellt man fest, dass auf dem Intel-Prozessor der Leser bei sehr kleinen Datensätzen fast vollständig blockiert wird. Auf dem AMD-Prozessor tritt dieser Effekt nicht auf. Wenn die Datenmengen größer werden, verhalten sich Intel und AMD ähnlich. Bei mittelgroßen Datensätzen liegt der Verlust auf beiden Prozessoren immer noch bei etwa 90 %.

Abbildung 4: Relativer Leistungsverlust bei gleichzeitigen Lese- und Schreiboperationen

Datenbusse

Die Ergebnisse der Leistungsmessungen (Abbildung 2 und 3) zeigen, dass die Bandbreite des Speicherbusses von den Kernen gemeinsam genutzt wird. Wenn die Kerne auf einem Datensatz arbeiten, der so groß ist, dass die Caches keine Wirkung haben, sinkt die Leistung auf 50 %, wenn beide Kerne aktiv sind. Der gleiche Effekt wurde auf dem PCI-Bus gemessen. Während eine Cache-Trefferrate von 0 % beim Speicherzugriff sehr unwahrscheinlich sein mag, ist sie auf dem PCI-Bus der Normalfall, da auf PCI-Geräte in der Regel mit deaktivierten Caches zugegriffen wird.

Gemeinsam genutzte E/A-Geräte

Die durch den gleichzeitigen Zugriff auf ein gemeinsam genutztes E/A-Gerät verursachte Leistungsminderung hängt hauptsächlich von dem Bus ab, der das Gerät mit dem Prozessor verbindet (z. B. der PCI-Bus), sowie von dem Gerät selbst. Ein Gerät, das nur eine Anfrage zur gleichen Zeit bearbeiten kann, kann eine zweite Anfrage für Hunderte von Mikrosekunden blockieren.

Gemeinsam genutzte Interrupts

Auf einer Multi-Core-Plattform wird ein Hardware-Interrupt in der Regel an einen Kern weitergeleitet. Wenn mehrere Geräte an eine Interrupt-Leitung angeschlossen sind und die Geräte nicht von demselben Kern bedient werden, muss der Kern, der den Interrupt empfängt, diesen Interrupt auch an den/die anderen Kern(e) weiterleiten und sie zwingen, den Interrupt-Status ihrer Geräte zu überprüfen. Gemeinsame Interrupts können zu erheblichen Interferenzen zwischen den Kernen führen und müssen durch ein geeignetes Plattformdesign vermieden werden.

Software-Störungskanäle

Eine der wichtigsten Komponenten eines IMA-Moduls ist die Kernsoftware einschließlich des Betriebssystems. Die Kernsoftware muss eine Ausführungsumgebung für die gehosteten Anwendungen bereitstellen, die einerseits die Plattformmerkmale vor den gehosteten Anwendungen verbirgt und andererseits die Nutzung der Plattformressourcen für alle Anwendungen streng kontrolliert. Während die meisten Hardware-Plattformen und Betriebssysteme auf eine optimierte durchschnittliche Rechenleistung ausgelegt sind, müssen die IMA-Module den Anwendungen eine hohe und konstante Rechenbandbreite gemäß dem vordefinierten Zeitplan zur Verfügung stellen. Die Systemsoftware muss eine unbeabsichtigte Kopplung zwischen den Partitionen aufgrund des Zugriffs auf gemeinsam genutzte Ressourcen verhindern und darf keine zusätzlichen Störungskanäle durch den gleichzeitigen Zugriff auf die Systemsoftware selbst einführen. Im Vergleich zu einem Single-Core-Design, bei dem sich die asynchrone Plattformnutzung mit Auswirkungen auf die laufende Anwendung hauptsächlich auf die Interrupt-Verarbeitung und von E/A-Geräten initiierte DMA-Transfers beschränkt, ist der asynchrone Zugriff auf Plattform- und Systemsoftware-Ressourcen der Normalfall auf Multi-Core-Plattformen.

Die Vielfalt der CPU- und Plattformarchitekturen und der funktionalen Anforderungen führt zu unterschiedlichen Konzepten der Multi-Core-Unterstützung in der Kernsoftwarekomponente. Für eine Dual-Core-CPU könnte ein angepasstes ARINC 653 Zeitpartitionierungskonzept angemessen sein, während bei einer CPU mit 32 oder mehr Kernen eine Zeitpartitionierung möglicherweise nicht mehr sinnvoll ist. Im Folgenden gehen wir von einem Systemsoftware-Design aus, das mit dem ARINC 653 Partitionierungskonzept kompatibel ist, aber wir nehmen an, dass bestimmte Partitionen möglicherweise mehrere Kerne nutzen müssen.

Software-Konzepte für Multi-Core-Plattformen

Die Interferenz zwischen Softwarekomponenten, die gleichzeitig auf verschiedenen Kernen laufen, hängt hauptsächlich von der Softwarearchitektur und der Art und Weise ab, wie die Software die Kerne nutzt. In den folgenden Abschnitten werden die verschiedenen Konzepte für die Verwendung von Multi-Core-Prozessoren und die damit verbundenen Interferenzprobleme erörtert.

Betriebssystem-Ebene

Auf der Ebene des Betriebssystems werden zwei Konzepte zur Nutzung mehrerer Prozessorkerne unterschieden:

Das Asymmetric Multi-Processing (AMP oder ASMP) und das Symmetric Multi-Processing (SMP).

Beim AMP-Konzept wird eine Multi-Core-Prozessorplattform ähnlich wie ein Multiprozessorsystem verwendet. Jeder Kern führt seine eigene, auf einen Kern bezogene Systemsoftwareschicht aus. Die Kerne sind über verschiedene Kommunikationskanäle lose gekoppelt, die auf Interrupts zwischen den Prozessoren, bestimmten gemeinsam genutzten Speicherbereichen oder anderen externen Geräten basieren können.

Die wichtigsten Vorteile des AMP-Konzepts sind: 

• Die Systemsoftwareschicht muss nicht Multi-Core-fähig sein, was den Entwurf vereinfacht.
• Es gibt keine implizite Kopplung durch gemeinsam genutzte Daten und kritische Abschnitte innerhalb der Systemsoftwareschicht.
• Jeder Kern kann eine Systemsoftwareschicht ausführen, die für die auszuführende Aufgabe optimiert ist. Ein Beispiel hierfür ist eine Dual-Core-Plattform, bei der ein Kern für die E/A-Verarbeitung und Datenkonzentration zuständig ist, während auf dem anderen Kern ein ARINC-653-konformes Betriebssystem läuft, auf dem die Anwendungen laufen.

Die Nachteile des AMP-Ansatzes sind: 

• Alle Systemsoftware-Instanzen müssen auf der höchsten für die Plattform geltenden Stufe zertifiziert sein, da sie vollen Zugriff auf privilegierte Prozessorregister und -befehle haben.
• Die Partitionierung der Plattformressourcen ist komplizierter, insbesondere wenn verschiedene Systemsoftwareschichten verwendet werden. Dies beschränkt den Einsatz des APM-Konzepts auf CPUs mit einer geringen Anzahl von Kernen.
• Die Synchronisierung zwischen Anwendungen, die auf verschiedenen Kernen laufen, ist komplexer.
• Der AMP-Ansatz unterstützt keine parallele Ausführung auf Anwendungsebene.

Interferenzen auf einer AMP-Plattform werden hauptsächlich durch gemeinsam genutzte Caches, Speicher- und E/A-Busse und den gleichzeitigen Zugriff auf gemeinsam genutzte Geräte verursacht. Interferenzen auf dem Speicherbus sind schwer zu vermeiden, während der Zugriff auf E/A-Geräte auf einen Kern beschränkt sein kann. Kohärenzprobleme beschränken sich auf einzelne Kommunikationspuffer, und die von der Systemsoftware verursachten Störungen beschränken sich auf gemeinsam genutzte Gerätehandles.

Beim SMP-Konzept wird eine Systemsoftwareinstanz zur Steuerung aller Kerne und Plattformressourcen verwendet. Das Betriebssystem bietet in der Regel Kommunikationsdienste zwischen und innerhalb von Partitionen, die die kernübergreifende Kommunikation transparent verwalten. Die Gerätetreiber sind für die Verwaltung des gleichzeitigen Zugriffs auf die Plattformressourcen zuständig.

Die Vorteile des SMP-Ansatzes sind: 

• Es gibt nur eine Systemsoftwareinstanz, die für das Partitionierungskonzept verantwortlich ist, wodurch sich der Zertifizierungsaufwand auf ein Softwarepaket beschränkt.
• Es ist nur eine Plattformkonfigurationsschicht erforderlich.
• Die SMP-Systemsoftware kann die Ausführung kritischer Aufgaben vollständig isolieren, indem sie z. B. die gleichzeitige Ausführung von nicht vertrauenswürdigen Partitionen vorübergehend deaktiviert.
• SMP bietet viel mehr Flexibilität und ermöglicht einen besseren Lastausgleich als eine AMP-Konfiguration.
• Die parallele Ausführung auf Anwendungsebene kann unterstützt werden, wenn Interferenzen zwischen Kernen keine Rolle spielen, z. B. bei nicht sicherheitsrelevanten Partitionen.

Die Hauptnachteile des SMP-Ansatzes sind:

• Die Systemsoftwareschicht ist komplexer, da sie ihre internen Daten vor gleichzeitigem Zugriff schützen muss, ohne dass dies erhebliche Auswirkungen auf parallele Dienstanforderungen hat.
• Die internen Daten müssen sehr sorgfältig angeordnet werden, um False-Sharing-Effekte zu vermeiden.
• Aufgrund der gemeinsam genutzten Systemsoftwareschicht lässt sich eine implizite Kopplung nicht zusammenhängender Ausführungsthreads nicht vollständig vermeiden.

Im Vergleich zu einer AMP-Konfiguration fügt der SMP-Ansatz eine wichtige Quelle potenzieller Störungen hinzu, nämlich die gemeinsam genutzte Systemsoftwareschicht. Ein sorgfältiger Entwurf kann jedoch die Auswirkungen durch die Implementierung feinkörniger kritischer Abschnitte begrenzen. Die internen Daten der Systemsoftwareschicht müssen sorgfältig angeordnet werden, um eine unbeabsichtigte Kopplung aufgrund einer falschen gemeinsamen Nutzung zu vermeiden.

Parallele Ausführung auf Thread-Ebene

Parallele Ausführung auf Thread-Ebene bedeutet, dass der Programmierer eine Anwendung in mehrere Ausführungs-Threads unterteilt und diese Threads an einen Prozessorkern bindet. Die Threads arbeiten in der Regel mit denselben Daten, z. B. den Anwendungsdaten, BSS- und Heap-Segmenten. Alle Effekte, die im Zusammenhang mit gemeinsam genutzten Caches, Cache-Kohärenz (insbesondere False Sharing) und Bus-Sharing diskutiert werden, müssen berücksichtigt werden, um die Worst-Case-Leistung einer solchen Anwendung zu bestimmen. Durch die explizite Erstellung von Threads hat der Programmierer mehr Kontrolle über den gleichzeitigen Zugriff auf gemeinsam genutzte Ressourcen als im Falle der parallelen Ausführung auf Blockebene mit dem OpenMP-Ansatz. Interferenzen zwischen Threads der gleichen Partition können für die Anwendung selbst zu Zeitproblemen führen, haben aber an sich keine Auswirkungen auf die Partitionierung.

Parallele Ausführung auf Anweisungsebene

Bestimmte Teile eines logischen Ausführungs-Threads können von mehreren Prozessorkernen parallel ausgeführt werden, wenn die verarbeiteten Eingangs- und Ausgangsdaten unabhängig sind. Die OpenMP-Anwendungsprogrammschnittstelle [5] definiert Compilerdirektiven, die Codeabschnitte angeben, die parallel ausgeführt werden können. Die OpenMP-Implementierung verwendet das fork/join-Konzept, bei dem der Haupt-Thread eine bestimmte Anzahl von Worker-Threads zur Ausführung des als parallel gekennzeichneten Codeabschnitts abzweigt. Nach Abschluss des parallelen Blocks schließen sich die Worker-Threads wieder mit dem Haupt-Thread zusammen. Die Zuweisung der Codeanweisungen an die Worker-Threads erfolgt durch den Compiler. Die Überlegungen zu Interferenzen sind dieselben wie bei der parallelen Ausführung auf Thread-Ebene, aber das Risiko einer falschen Aufteilung kann aufgrund der reduzierten Datenmengen auf Block-Ebene sogar höher sein.

Ein SMP-Konzept für IMA

In den vorangegangenen Abschnitten haben wir verschiedene Konzepte für die Verwendung von Mehrkernprozessoren erörtert. Der AMP-Ansatz ist für spezialisierte Lösungen interessant, insbesondere wenn er auf einer Dual-Core-Plattform eingesetzt wird, bei der ein Kern vollständig für die E/A-Verarbeitung zuständig ist und auf dem anderen Kern die Anwendungssoftware läuft. Die durch den E/A-Prozessor verursachte Störung ist überschaubar, da er vollständig unter der Kontrolle der (vertrauenswürdigen) Plattformsoftware läuft. Dieser Ansatz scheint als erster Schritt in Richtung Multi-Core-IMA sinnvoll zu sein, bietet aber keine nennenswerte zusätzliche Verarbeitungsbandbreite für die Anwendungen.

Ein generischerer Ansatz ist die Verwendung eines SMP-Betriebssystems, da es mit einer zunehmenden Anzahl von CPU-Kernen besser skaliert und eine höhere Flexibilität bietet.

Wir gehen davon aus, dass künftige IMA-Plattformen neben den kritischen Anwendungen auch eine wachsende Zahl von Anwendungen mit hohen Leistungsanforderungen, aber geringerer Kritikalität beherbergen müssen. Diese Anwendungen müssen auch nicht unbedingt auf der ARINC 653 Intra-Partition-API basieren, sondern können Laufzeitumgebungen wie POSIX®, Java oder sogar Linux erfordern. Sie können auch Multiprocessing auf Anwendungsebene erfordern.

Aufgrund der potenziellen Interferenzen zwischen den Anwendungen scheint es nicht machbar zu sein, eine sicherheitskritische Anwendung gleichzeitig mit einer nicht vertrauenswürdigen Anwendung laufen zu lassen. Das Betriebssystem muss den exklusiven Zugang zur Plattform für die kritischsten Anwendungen unterstützen. Intra-Partition-Multiprocessing für sicherheitskritische Anwendungen scheint ebenfalls fragwürdig zu sein, da die Analyse der Ausführungszeit im schlimmsten Fall unmöglich werden könnte.

Wenn keine kritische Anwendung läuft, kann die Plattform zwischen den Partitionen geteilt werden oder alle Kerne können der anspruchsvollsten Anwendung zur Verfügung gestellt werden.

Das Betriebssystem PikeOS ist ein gutes Beispiel dafür, dass der Bedarf an Hochleistungsrechnern für weniger kritische Anwendungen und ein hohes Maß an Determinismus und Isolierung für hochkritische Anwendungen auf einer Multicore-Plattform realisiert werden kann.

PikeOS bietet ein ARINC 653-konformes Partitionierungsmodell, das zusätzlich zur ARINC 653 API die Ausführung verschiedener Laufzeitumgebungen und APIs wie POSIX®, ADA, Java oder sogar ein vollständig virtualisiertes Linux innerhalb einer Partition ermöglicht.

Der Scheduler führt einen gemeinsamen Major Time Frame (MAF) aus, der das Betriebssystem vollständig ARINC 653-konform hält. Die CPU-Kerne werden statisch den Ressourcenpartitionen zugewiesen, wobei eine Ressourcenpartition mehrere Kerne nutzen kann. Abbildung 5 zeigt eine mögliche Konfiguration des PikeOS-Partitions-Schedulers:

Abbildung 5: Beispielkonfiguration und Laufzeitmodell unter Verwendung des PikeOS Partition Schedulers

Die angenommene Plattform basiert auf einer Quad-Core-CPU. Der Hauptzeitrahmen ist in drei Partitionsfenster unterteilt.

Eine kritische Single-Core-Anwendung soll exklusiven Zugriff auf einen der Kerne haben und während ihres Zeitfensters exklusiven Zugriff auf die gesamte Plattform haben. Eine leistungsfordernde Partition hat während ihres Zeitfensters exklusiven Zugriff auf die übrigen drei Kerne. Ein Zeitfenster wird von zwei Ressourcenpartitionen gemeinsam genutzt. Eine Partition läuft auf zwei Kernen und die andere auf einem Kern. Während eines Zeitfensters hat die gesamte Plattform während ihres Zeitfensters Zugriff.

Die gewählte Konfiguration konzentriert sich auf ein maximales Maß an Isolation für die kritische Anwendung und nimmt dabei eine erhebliche Verschwendung von CPU-Zeit in Kauf. Partition 3 ist die einzige Partition, die auf Kern "C" ausgeführt wird, und während des Zeitfensters von Zeitpartition 3 wird keine andere Partition ausgeführt. Dadurch werden jegliche Störungen auf Hardware- und Softwareebene vermieden. Das Maß an Determinismus ist bei dieser Konfiguration sogar besser als bei einer herkömmlichen IMA-Plattform, da die kritische Anwendung den Kern nicht mit anderen Partitionen teilt, wodurch auch der Zustand der privaten Caches unverändert bleibt. Dies ist natürlich eine recht teure Konfiguration, da 5 von 12 Zeitfenstern in einem Major Time Frame ungenutzt sind.

Eine Konfiguration, die mit den bestehenden IMA-Konfigurationen vergleichbar ist, würde die Nutzung des Kerns "C" während Tp_1 und Tp_2 erlauben und die Anzahl der ungenutzten Zeitfenster auf 3 reduzieren.

Zusammenfassung

Der Einsatz von Multi-Core-CPUs ist für künftige Avionikplattformen, einschließlich IMA-Plattformen, erforderlich, um den steigenden Leistungsanforderungen gerecht zu werden. Ein großes Problem ist die Komplexität dieser CPUs, insbesondere wenn sie als MPSoCs bereitgestellt werden. Multi-Core-CPUs müssen in der Avionik in weniger kritischen Systemen eingeführt werden, um Erfahrungen im Betrieb zu sammeln und zu bewerten, ob sie für kritische Systeme geeignet sind. Um genügend Daten zu erhalten, kann eine Zusammenarbeit innerhalb der Avionikindustrie erforderlich sein. Multi-Core-Plattformen können zusätzliche Hardware- und Software-Interferenzkanäle zwischen Partitionen, die gleichzeitig auf verschiedenen Kernen ausgeführt werden, einführen, die durch ein intelligentes System-Software-Design beseitigt werden müssen. Bei der Auswahl des Prozessors sollten die Auswirkungen gemeinsam genutzter Caches berücksichtigt werden, und beim Entwurf der Plattform müssen gemeinsame Unterbrechungen vermieden und E/A-Busse und E/A-Geräte berücksichtigt werden.

Mit dem Betriebssystem PikeOS haben wir gezeigt, dass ein ARINC 653-konformes Betriebssystem Multi-Ccore-CPUs auf IMA-konforme Weise unterstützen kann. Eine Plattform kann so konfiguriert werden, dass sich kritische Anwendungen noch deterministischer verhalten als auf heutigen IMA-Plattformen, wenn ein gewisser Anteil an ungenutzter Bandbreite akzeptabel ist. Aufgrund der höheren Leistung können Multi-Core-Plattformen zu mehr funktionaler Sicherheit beitragen, da sie die notwendige Leistung für die Implementierung zusätzlicher Redundanz bereitstellen können.

Referenzen

[1] Dr. Eugene Normand, December 16, 1998, Single Event Effects in Avionics, Boeing Radiation Effects Lab, (C-17-SEU-Present.pdf)

[2] Philip P. Shirvani and Edward J. May 2001, McCluskey, SEU Characterization of Digital Circuits Using Weighted Test Programs, Center for Reliable Computing, Stanford University

[3] Udo Steinberg, 29.04.2010, Parallel Architectures - Memory Consistency & Cache Coherency, Technische Universität Dresden, Department of Computer Science-Institute of Systems Architecture, Operating Systems Group, os.inf.tu-dresden.de/Studium/DOS/SS2010/02-Coherency.pdf

[4] Tian Tian, Chiu-Pi Shih, February 24, 2009,Software Techniques for Shared-Cache Multi-Core Systems, Intel Software Network, http://software.intel.com/en-us/articles/software-techniques-for-shared-cache-multi-core-systems/

[5] OpenMP Architecture Review Board, May 2005, OpenMP Program Interface, Version 2.5, OpenMP Architecture Review Board