Zertifizierung von sicherheitskritischen System auf Multicore

ZERTIFIZIERUNG VON SICHERHEITSSYSTEMEN
AUF MULT-CORE BASIS
Von Rudolf Fuchsen und Mehmet Özer, SYSGO AG, Klein-Winternheim, Deutschland
Zusammenfassung
Hypervisor basierte Separation/Trennung ist eine effektive Methode, um ein zertifizierbares
Sicherheitssystem zu erstellen. Die Luftfahrtelektronik hat diese Idee übernommen und setzt dieses Konzept mit
der Richtlinie ARINC 653 für softwarebasierte Sicherheitssysteme um. In der Automobilindustrie wird dasselbe
Konzept angewandt, um die Sicherheit von Fahrerassistenzsystemen zu gewährleisten und mehrere Steuergeräte
in einem mehrfach partitionierten System (ECU-Konsolidierung) zu kombinieren. In der Bahnindustrie
verwenden Sicherheitssysteme wie Communication-Based Train Control (CBTC) und softwarebasierte
Stellwerksysteme eine Separation mittels Hypervisor, um die softwarebasierte SIL4-Sicherheit zu gewährleisten.
Ein robuster Hypervisor garantiert eine rückwirkungsfreie Trennung, sodass Anwendungen mit mehreren
Kritikalitätsstufen auf einer Hardware-Plattform konsolidiert werden können. Sicherheitsfunktionen,
Informationsdienste und Komfortfunktionen können gleichzeitig mit einer Hardware bereitgestellt werden,
wodurch Größe, Gewicht und Leistungsverbrauch (SWAP) optimiert werden. Parallel wächst die Anforderung
an die Rechenleistung.
Der traditionelle Ansatz zur Bereitstellung einer höheren Rechenleistung war, die Taktfrequenz des
Prozessors zu erhöhen, durch Befehlspipelines und spekulative Programmausführungen die pseudo-parallele
Verarbeitung auf Befehlsebene zu steigern sowie die Cache-Größe und Anzahl der Cache-Ebenen zu erhöhen.
Mit der heutigen Technologie hat dieser Ansatz seine Grenzen erreicht. Die Erhöhung der Prozessorfrequenz
führt zu einem unverhältnismäßig hohen Stromverbrauch und damit zu einer unverhältnismäßig hohen
Verlustleistung. Chip-interne und -externe Übersprecher/Crosstalks, Signalverzögerungen und Reflexionen sind
weitere Probleme, die durch eine höhere Taktfrequenz bedingt werden. Die bestehende Parallelität und
Abhängigkeiten auf der Code-Ebene verhindern zudem eine weitere Leistungssteigerung durch
Parallelausführung auf Befehlsebene. Um die Prozessorleistung weiter zu erhöhen, ist die Chip-Industrie bei
Hochleistungsprozessoren auf das Mehrkernkonzept (Multi-Core) umgestiegen.
Dieser Artikel befasst sich mit der Frage, ob eine Plattform auf Mehrkernbasis (Multi-Core) dasselbe Maß
an Determinismus erreichen kann wie eine Einkernplattform (Single-Core), da dies ein wichtiger Aspekt für
eine Sicherheitszertifizierung darstellt. Im Folgenden werden die potenziellen Hardware- und SoftwareInterferenzkanäle einer Plattform auf Mehrkernbasis analysiert.
© 2016 SYSGO AG // www.sysgo.com
1
Überlegungen zur Zertifizierung
Für die Integration von Software-Diensten mit unterschiedlicher Funktionalität, Robustheit und Sicherheit
sowie unterschiedlichen Sicherheitsanforderungen ist eine eingebettete Plattform erforderlich, die





ausreichend Prozessorleistung, Speicherressourcen und E/A-Bandbreite bereitstellt;
ausreichende Zuverlässigkeit bietet;
ein deterministisches und vorhersagbares Echtzeitverhalten besitzt;
eine sichere und stabile Partitionierung der Ressourcen und Prozessorzeit unterstützt;
nach den geltenden Sicherheitsstandards zertifizierbar ist.
Processor Design Assurance
Historisch gesehen verwendeten hochkritische Sicherheitsplattformen typischerweise Einkernprozessoren,
die meist auf einer RISC-Architektur mit einer recht einfachen Cache und Pipeline-Architektur basieren.
Design-Unterlagen stehen in einem gewissen Ausmaß zur Verfügung, um den Zertifizierungsvorgang zu
unterstützen. Aufgrund ihrer häufigen Verwendung, gibt es zahlreiche Informationen über den bewährten
Betrieb, was das Risiko unerkannter systematischer Fehler reduziert. Zertifizierungsstellen haben
Sicherheitsplattformen auf Basis dieser Prozessoren für Anwendungen auf höchster Kritikalitätsstufe schon
mehrfach zertifiziert (z.B. DO-178B DAL A oder EN 50128 SIL4).
Mehrkernprozessoren als typische Nachfolger hochentwickelter Einkernprozessoren, übernehmen die
Prinzipien wie komplexe Befehlspipelines, Sprungvorhersagen und mehrstufige Caches. Zudem benötigen sie
Cache-Kohärenz-Module und Cross-Connects, um die Kerne miteinander zu verbinden. Mehrkernprozessoren
sind die modernsten Entwicklungen der Chip-Technologie. Chip-Hersteller tun sich deshalb schwer, detaillierte
Informationen über das Design der Chips bereitzustellen, die zur Zertifizierung der Plattform erforderlich sind.
Aufteilung von Zeit und Prozessorressourcen
Ein- und Mehrkernprozessoren verwenden dieselben Verfahren für den Ressourcenschutz. Beide wenden
das Konzept der Privilege-Levels (Supervisor and User) an und verfügen über eine Memory Management Unit
(MMU), um den Zugriff auf privilegierte Befehls- und Prozessorregister, physikalischen Speicher und im
Speicher abgebildete E/A-Geräte zu kontrollieren. Im Hinblick auf die Zertifizierung der RessourcenPartitionierung besteht kein wesentlicher Unterschied zwischen Ein- und Mehrkernplattformen.
Die Zeitpartitionierung ist bei einem System auf Mehrkernbasis komplizierter. Bei einem Einkernprozessor
gibt es immer nur einen einzelnen Thread. Dieser Thread kann durch ein asynchrones Ereignis unterbrochen
werden. In diesem Fall wird die Kontrolle an den Handler übergeben. Dabei gibt es keine konkurrierende
Ausführung. Eine Ausnahme kann ein E/A-Gerät sein, das Direct Memory Access (DMA) nutzt. Auf einem
Mehrkernprozessor stellt die parallele Ausführung den Normalfall dar, was zu Interferenzen zwischen den
Anwendungen führen kann, die auf den verschiedenen Kernen ausgeführt werden.
Hardware-Interferenzkanäle
Die Ausführung von Anwendungen, die auf den verschiedenen Kernen eines Mehrkernprozessors
ausgeführt werden, erfolgt nicht unabhängig voneinander. Auch wenn es zwischen diesen Anwendungen keinen
expliziten Datenfluss oder Steuerungen gibt, besteht eine Kopplung auf Plattformebene, da Plattformressourcen
implizit geteilt werden. Eine Plattformeigenschaft, die zu Interferenzen zwischen unabhängigen Anwendungen
führen kann, nennt sich Hardware-Interferenzkanäle. Die Analyse von Hardware-Interferenzkanäle erfordert
eine tiefgreifende Kenntnis der Plattform-Architektur einschließlich der Prozessor-Strukturen.
© 2016 SYSGO AG // www.sysgo.com
2
Die in dieser Abhandlung analysierten Mehrkernprozessoren besitzen ein Unified Memory Model, was
bedeutet, dass sich alle Kerne denselben physikalischen Adressraum teilen. Dadurch wird die Plattform
vereinfacht, da nur ein externer Prozessorbus erforderlich ist und die Kommunikation zwischen den Kernen über
den gemeinsamen physikalischen Speicher erfolgt. Abbildung 1 zeigt die typische Architektur einer solchen
Plattform.
Abbildung 1. Plattform auf Doppelkernbasis
Einige der Hardwarekomponenten, wie der Speichercontroller, der PCI-Controller oder andere E/A-Geräte
können mit dem Prozessor integriert sein, um ein Multiprozessor-Ein-Chip-System (MPSoC) zu bilden.
Prozessorkerne
Es wird angenommen, dass Prozessorkerne unabhängig voneinander arbeiten, solange sie nicht auf
gemeinsame Ressourcen zugreifen oder Inter Processor Interrupts (IPIs) verwenden. IPIs werden zusammen
mit den Software-Interferenzkanälen angegangen, da sie aktiv durch die Software ausgelöst werden müssen.
Caches
Zwei verschiedene Aspekte der Cache-Architektur können Interferenzkanäle zwischen Prozessoren
darstellen: die Cache-Kohärenz und der gemeinsame Cache.
Das Speichersystem kann als hierarchisches System angesehen werden: Auf der untersten Stufe befindet
sich der Prozessorkern, über dem sich eine oder mehrere Cache-Ebenen befinden und an der Spitze steht der
Speicher. Der Cache, der direkt mit dem Prozessor verbunden ist, ist der L1-Cache, auf welchen der L2-Cache
folgt usw. Die höchste Cache-Ebene ist mit dem externen Bus und somit mit dem Hauptspeicher verbunden.
Eine Datenabfrage, die auf einer bestimmten Ebene nicht erfüllt werden kann, wird auf die nächsthöhere
Ebene übertragen. Mit zunehmender Cache-Ebene nimmt auch die Cache-Größe zu. Es erhöht sich jedoch auch
die Latenzzeit für jeden Speicherzugriff.
Gemeinsamer Cache
Der L1-Cache ist in der Regel in einen Datencache und einen Befehlscache unterteilt, während alle anderen
Ebenen Daten und Befehle speichern.
© 2016 SYSGO AG // www.sysgo.com
3
Die meisten Mehrkernprozessoren besitzen einen eigenen L1-Daten- und-Befehlscache für jeden Kern,
während sich die Architektur der L2- und L3-Caches je nach Prozessorfamilie unterscheidet.
Gemeinsam verwendeter Cache ist in einem Mehrkernprozessor einer der Hauptgründe für Interferenzen.
Ein Vergleich des Lese- und Schreibdurchsatzes zwischen Doppelkernprozessoren von INTEL und AMD zeigt
die Auswirkungen eines gemeinsam genutzten L2-Cache. Der Intel-Prozessor verfügt über einen eigenen L1Cache für jeden Kern. Der L2-Cache wird von beiden Kernen gemeinsam benutzt. Der AMD-Prozessor besitzt
getrennte L1- und L2-Caches für jeden Kern. Abbildung 2 zeigt die Ergebnisse für beide Prozessoren. Wenn der
Datensatz klein genug ist, um in den (für jeden Kern eigenen) L1-Cache zu passen, zeigen der Intel- und der
AMD-Prozessor keinen Leistungsverlust, wenn der zweite Kern aktiv wird. Wenn der Datensatz kleiner als der
den Kernen zugängliche L2-Cache ist und dieser nicht gemeinsam genutzt wird (AMD-Prozessor), verursacht
der zweite Kern ebenso keinen Leistungsabfall. Wenn der Datensatz jedoch kleiner als der für einen Kern
verfügbare L2-Cache ist und der L2-Cache gemeinsam genutzt wird (Intel-Prozessor), hängt der
Leistungsverlust durch den zweiten Kern von der Größe des Datensatzes ab und liegt zwischen 30 und 95 % für
Schreibvorgänge und zwischen 19 und 92 % für Lesezugriffe. Die größte Auswirkung (92 %) ist dann
festzustellen, wenn der Datensatz der Größe des L2-Cache genau entspricht. Mit einem Kern passen die Daten
nämlich noch vollständig in den L2-Cache, während mit zwei Kernen alle Daten vom Speicher abgerufen
werden müssen, was bedeutet, dass wir die Leistung des L2-Cache mit der Leistung des Speicherbusses
vergleichen.
Ist der Datensatz deutlich größer als der L2-Cache, liegt der größte durch den zweiten Kern verursachte
Leistungsverlust bei rund 50 % für Lese- und Schreibvorgänge.
Abbildung 2. Lese- und Schreibdurchsatz auf getrennten Datensätzen (MByte)
Cache-Kohärenz
Ein weiterer wichtiger Aspekt bei der Cache-Verwendung ist die Konsistenz der lokalen Caches, die mit
einer gemeinsam genutzten Ressource verbunden sind. In Mehrkernsystemen mit Unified Memory ist die
Cache-Kohärenz von besonderer Bedeutung. Cache-Kohärenz bedeutet: „Wenn einer der lokalen Caches des
Kerns CA einen Bezug zur physikalischen Ressource Px besitzt und der im Cache gespeicherte Wert aktueller ist
als der in der Ressource Px gespeicherte, muss jeder Lesezugriff von jedem Kern (einschließlich dem Kern CA)
den im Cache des Kerns CA gespeicherten Wert bereitstellen.“ Die Kohärenz zwischen den Caches wird mit
Hilfe des Cache-Kohärenz-Protokolls aufrechterhalten.
© 2016 SYSGO AG // www.sysgo.com
4
Wenn beide Kerne nur lesen, zeigt der zweite Kern im Falle des Intel-Prozessors über den gesamten
Datensatz-Bereich fast keine Auswirkungen auf die Leistung, während die Leistung beim AMD-Prozessor auf
50 % sinkt, wenn der Datensatz größer als der L2-Cache ist. Wenn beide Kerne nur schreiben, wird der IntelProzessor vom gleichzeitigen Schreiben viel weniger beeinträchtigt als der AMD-Prozessor. Die Abhängigkeit
von der Datensatzgröße ist jedoch ähnlich (siehe Abbildung 3).
Abbildung 3. Lese- und Schreibdurchsatz auf gemeinsame Datensätze (MByte)
Wenn ein Kern denselben Datensatz liest, den der andere Kern schreibt, verhalten sich der Intel- und der
AMD-Prozessor vollkommen unterschiedlich. Abbildung 4 zeigt den relativen Datendurchsatz für beide
Prozessoren im Vergleich zum Datendurchsatz, wenn nur ein Kern aktiv ist. Beim Intel-Prozessor wird der
schreibende Prozessor von einem gleichzeitigen Lesevorgang viel weniger beeinträchtigt als beim AMDProzessor. Der höchste Leistungsverlust erreicht jedoch ebenfalls 90 %, sollte die Datensatzgröße 4 MByte
betragen.
Beim AMD-Prozessor liegt der Leistungsverlust bei kleinen Datensätzen bei 99 %, bei großen Datensätzen
bei rund 50 %. Wenn wir den Verlust der Leseleistung vergleichen, kommen wir zum Schluss, dass auf dem
Intel-Prozessor das Lesen bei sehr kleinen Datensätzen beinahe vollständig blockiert wird. Beim AMDProzessor ist diese Auswirkung nicht zu beobachten. Werden die Datensätze größer, verhalten sich der Intelund der AMD-Prozessor ähnlich. Für mittelgroße Datensätze beträgt der Verlust rund 90 % für beide
Prozessoren.
Abbildung 4. Relativer Leistungsverlust bei gleichzeitigen Lese- und Schreibvorgängen
© 2016 SYSGO AG // www.sysgo.com
5
Datenbusse
Die Ergebnisse der Leistungsmessungen (Abbildungen 2 und 3) zeigen, dass die Bandbreite des
Speicherbusses zwischen den Kernen geteilt wird. Wenn die Kerne einen Datensatz bearbeiten, der so groß ist,
dass die Caches keinen Einfluss haben, sinkt die Leistung auf 50 % ab, wenn beide Kerne aktiv sind. Dieselbe
Wirkung wurde auf dem PCI-Bus gemessen. Während eine Cache-Trefferrate von 0 % beim Speicherzugriff
sehr unwahrscheinlich ist, stellt sie auf dem PCI-Bus den Normalfall dar, da auf PCI-Geräte normalerweise mit
deaktivierten Caches zugegriffen wird.
Gemeinsame E/A-Geräte
Die durch gleichzeitigen Zugriff auf gemeinsame E/A-Geräte hervorgerufene Leistungsminderung hängt
hauptsächlich vom Bus ab, der das Gerät mit dem Prozessor verbindet (z.B. der PCI-Bus) sowie vom Gerät
selbst. Ein Gerät, das nur eine Anfrage nach der anderen bearbeiten kann, kann eine zweite Anfrage für
Hunderte von Mikrosekunden blockieren.
Geteilte Interrupts
Auf einer Mehrkernplattform wird ein Hardware-Interrupt in der Regel auf einen Kern geleitet. Sind
mehrere Geräte mit einer Interrupt-Leitung verbunden, und werden diese Geräte nicht vom selben Kern bedient,
muss der Kern, der den Interrupt empfängt diesen an den/die anderen Kern(e) weiterleiten und diese(n) dazu
bringen, den Interrupt-Status seiner/ihrer Geräte zu überprüfen. Geteilte Interrupts können erhebliche
Interferenzen zwischen den Kernen verursachen. Diese müssen durch ein geeignetes Plattformdesign verhindert
werden.
Software-Interferenzkanäle
Interferenzen zwischen Softwarekomponenten, die gleichzeitig auf verschiedenen Kernen laufen, hängen in
erster Linie von der Software-Architektur und der Art und Weise ab, wie die Software die Kerne verwendet. Auf
Betriebssystemebene werden zwei Konzepte für Mehrkern- und Mehrprozessor-Systeme unterschieden: das
asymmetrische Multiprozessorsystem (AMP) und das symmetrische Multiprozessorsystem (SMP).
Beim AMP-Ansatz wird eine Mehrkernprozessor-Plattform sehr ähnlich wie bei einem
Multiprozessorsystem eingesetzt. Jeder Kern führt seine eigene System-Software aus. Die Kerne sind über
verschiedene Kommunikationskanäle gekoppelt, die auf Inter Processor Interrupts (IPIs), gemeinsam genutzten
Speicherbereichen (Shared Memory) oder externen Geräten basieren können.
Interferenzen auf einer AMP-Plattform werden hauptsächlich durch gemeinsame Caches, Speicher und
E/A-Busse sowie den gleichzeitigen Zugriff auf gemeinsame Geräte verursacht. Interferenzen am Speicherbus
sind nur schwer vermeidbar, während der Zugriff auf E/A-Geräte auf einen Kern beschränkt werden kann.
Kohärenzprobleme sind auf unterschiedliche Kommunikationspuffer begrenzt. Die durch die Systemsoftware
hervorgerufenen Interferenzen beschränken sich auf gemeinsame Geräte-Handle.
Der SMP-Ansatz nutzt eine Instanz der Systemsoftware, um alle Kerne und Plattformressourcen zu steuern.
Das Betriebssystem stellt üblicherweise Dienste zur Inter- und Intrapartitionskommunikation bereit, die eine
transparente Kommunikation zwischen den Kernen verwalten. Die Gerätetreiber sind dafür verantwortlich, den
gleichzeitigen Zugriff auf Plattformressourcen zu verwalten.
Im Vergleich zu einer AMP-Konfiguration fügt der SMP-Ansatz eine bedeutende Quelle für mögliche
Interferenzen hinzu: die gemeinsame System-Softwareschicht. Ein sorgfältiges Design der kritischen Abschnitte
kann jedoch die Auswirkungen begrenzen.
© 2016 SYSGO AG // www.sysgo.com
6
Ein SMP-Ansatz für hochkritische Sicherheitssysteme
Der AMP-Ansatz ist für spezifische Lösungen interessant, vor allem bei der Anwendung auf Dual-core
Plattformen, bei denen ein Kern vollständig der E/A-Verarbeitung dient und der andere Kern die
Anwendungssoftware ausführt. Die durch den E/A-Prozessor hervorgerufene Interferenz ist überschaubar, da
dieser vollständig unter der Kontrolle der (vertrauenswürdigen) Software auf Plattformebene läuft. Dieser
Ansatz scheint ein sinnvoller erster Schritt in Richtung Sicherheitssysteme auf Mehrkernbasis zu sein. Es wird
jedoch keine wesentliche zusätzliche Verarbeitungsbandbreite für die Anwendungen erzielt.
Ein allgemeinerer Ansatz ist die Verwendung eines SMP-Betriebssystems, da es besser mit zunehmender
Anzahl der Prozessorkerne skaliert und erhöhte Flexibilität bietet.
Das folgende Beispiel erläutert die Verwendung einer Hypervisor-Technologie auf Basis eines
Separationskernel zur Steuerung eines Mehrkernprozessors, um die strengen Anforderungen mehrerer
Sicherheitsstandards zu erfüllen. Die Architektur eines Separationskernel folgt einem stark modularen Ansatz,
mit den Grundprinzipien Least-Privilege und minimaler Trusted-Code-Base. Der Separationkernel vereint einen
Mikrokernel, der Echtzeitverhalten und grundlegende Ressourcenverwaltung gewährleistet, mit einem
Hypervisor. Der Hypervisor sorgt durch Separation und kontrollierten Informationsfluss für Sicherheit. Die
Grundkomponenten eines solchen Echtzeit-Hypervisors sind virtuelle Maschinen, die in der Separationkernel
Fachbezeichnung Ressourcenpartitionen (RP) genannt werden. Die Partitionen beherbergen entweder ein
vollwertiges Betriebssystem wie z.B. Linux, oder eine Laufzeitumgebung wie POSIX oder JAVA oder
technologiespezifische Lösungen wie AUTOSAR oder ARINC 653 (siehe Abb. 5). Die Rechenzeit wird mittels
Zeitpartitionierung zugeteilt. Dafür wird ein zweistufiger Scheduler verwendet. Die erste Stufe teilt die
verfügbare Zeit in Zeitpartitionen (tp) auf und weist einer Zeitpartition eine oder mehrere Ressourcenpartitionen
zu. Die zweite Stufe schedulet die zu jeder Zeitpartition gehörenden Threads (aus den Ressource Partitionen)
auf FIFO- und Prioritätsbasis. Eine definierte Abfolge von Zeitpartitionen wird in einem Major Time-Frame
(MTF) gruppiert und zyklisch ausgeführt, immer wenn ein MTF beendet ist (siehe Abb. 5).
© 2016 SYSGO AG // www.sysgo.com
7
Abbildung 5. Zeit und Ressource Partitionierung für einen Separation-Kernel
Abbildung 6. Konfigurationsbeispiel und Laufzeitmodell unter Einsatz des PikeOS-Partitionschedulers
Die Prozessorkerne sind Ressourcenpartitionen statisch zugewiesen, wobei eine Ressourcenpartition
mehrere Kerne nutzen kann. Abbildung 6 zeigt eine mögliche Konfiguration des PikeOS-Partition-Schedulers:
© 2016 SYSGO AG // www.sysgo.com
8
Die angenommene Plattform basiert auf einem Vierkernprozessor. Der Major-Time-Frame ist in drei
Partitionsfenster unterteilt (tp1 bis tp3). Die sicherheitskritische Anwendung (RP3, rot) soll ausschließlichen
Zugriff auf einen der Kerne (Core_C) sowie exklusiven Zugriff auf die gesamte Plattform während ihres
Zeitfensters (tp3) haben. Eine rechenintensive Partition (RP2) soll während ihres Zeitfensters (tp2)exklusiven
Zugriff auf die verbleibenden drei Kerne besitzen. Eine weitere Zeitpartition (tp1) wird von zwei
Ressourcenpartitionen (RP1 und RP4) geteilt. RP1 wird auf zwei Kernen ausgeführt, RP4 auf einem Kern.
Die gewählte Konfiguration setzt auf ein Höchstmaß an Isolation für die kritische Anwendung und
akzeptiert dafür die Vergeudung von Prozessorzeit. Rp3 ist die einzige Partition, die auf Kern C ausgeführt
wird; während der Zeitscheibe der Zeitpartition tp3 wird keine andere Partition ausgeführt. Dadurch werden alle
Interferenzen auf Hardware- und Softwareebene eliminiert. Der Grad an Determinismus dieser Konfiguration ist
sogar höher als auf einer RTOS-basierten Plattform, da die kritische Anwendung den Kern nicht mit anderen
Partitionen teilt und dadurch der Zustand der privaten Caches unverändert bleibt.
Nichtsdestotrotz muss die Einstellung der Caches und Übersetzungspuffer (TLB) berücksichtigt werden.
Der PikeOS-Hypervisor stellt Mittel zur Verfügung, um Befehlscaches und TLBs zu invalidieren und den
Datencache zwischen den Umschaltungen der Zeitpartitionen zu leeren. Dadurch wird sichergestellt, dass sich
Caches und Übersetzungspuffer bei der Partitionsausführung in einem definierten Zustand befinden. Das Leeren
und invalidieren des Cache / Übersetzungspuffers erfolgt während der Umschaltung der Zeitpartition, wodurch
den eigentlichen Zeitpartitionen Prozessorzyklen verloren gehen (Jitter). Ein möglicher Ansatz ist, ein kleines
Zeitpartitionsfenster zu definieren, dem eine eigene Zeitpartitions-ID zugewiesen wird, und dieses vor der
Ausführung der zeitkritischen Anwendung einzufügen. Dadurch wird der Jitter der zeitkritischen Anwendung
eliminiert.
Vertikale Marktaspekte
Mit dem Positionspapier CAST 32 (Originalfassung) [3] haben die EASA und FAA eine Abhandlung
veröffentlicht, in welcher 24 Zielvorgaben zur Handhabung von Mehrkernprozessoren in Avioniksystemen auf
den Sicherheitsanforderungsstufen (DAL) A und B erörtert werden. Es wurde eine Untergruppe von 16 Zielen
ermittelt, um in Avioniksystemen der Stufe DAL C Mehrfachkerne anzuwenden. Die Abhandlung bezieht sich
nur auf Mehrkernprozessoren mit zwei aktiven Kernen. Das Positionspapier CAST 32 kann als sehr brauchbare
Einführung angesichts der Bedenken der Luftfahrtbehörden bezüglich des Einsatzes von Mehrfachkernen
verwendet werden.
Die Sicherheitsstandards für die Bahnindustrie (EN50128, EN50129) sind flexibler und erwähnen den
Einsatz von Multiprozessorsystemen für „Eisenbahnsteuerungs- und Überwachungssysteme “. Das
Hauptanliegen beim Einsatz von Mehrkernprozessoren ist die Bestimmung der maximalen Ausführungszeit
(Worst Case Execution Time, WCET). Die in dieser Abhandlung erörterten Hardware- und SoftwareInterferenzkanäle können die Bestimmung der maximalen Ausführungszeit unmöglich machen. Das
Unternehmen SYSGO hat die oben beschriebene Konfiguration für sein PikeOS-Echtzeit-Hypervisor
verwendet, um das weltweit erste SIL4-Zertifikat für ein Mehrkernsystem (Dual-Core Intel i7) zu erhalten.
Dieses Prinzip ist nicht auf Doppelkerne beschränkt, solange eine passende PikeOS-Konfiguration den
Prozessor deterministisch kontrollieren kann.
Literaturhinweise:
[1] – How to address certification for multi-core based IMA platforms; Rudolf Fuchsen, SYSGO AG
[2]- How hypervisor operating systems can cope with multi-core certification challenges; Sven
Nordhoff, SYSGO AG.
[3] - CAST-32, Mai 2014, Position Paper CAST-32 on Multi-core Processors, Originalfassung.
© 2016 SYSGO AG // www.sysgo.com
9