Ein Angebot von

Multicore-Determinismus für sicherheitskritische Anwendungen

| Autor / Redakteur: Richard Jaenicke * / Sebastian Gerstl

Raum-Zeit-Partitionierung: Bei sicherheitskritischen Anwendungen auf Multicore-Systemen kommt es nicht nur auf die räumliche, sondern auch die zeitliche Verteilung von Tasks über die Kerne an.
Raum-Zeit-Partitionierung: Bei sicherheitskritischen Anwendungen auf Multicore-Systemen kommt es nicht nur auf die räumliche, sondern auch die zeitliche Verteilung von Tasks über die Kerne an. (Bild: Clipdealer)

In Multicore-Prozessoren müssen sich mehrere Kerne gemeinsame Ressourcen teilen. Das kann in sicherheitskritischen Anwendungen die zeitliche wie räumliche Verteilung von Tasks herausfordernd gestalten.

Alle Multicore-Hardwarearchitekturen umfassen gemeinsam genutzte Ressourcen wie Speicher-Controller, DDR-Speicher, I/Os, Cache und die interne Struktur, die sie verbindet (Bild 1). Konflikte um diese gemeinsam genutzten Ressourcen treten auf, wenn mehrere Prozessorkerne gleichzeitig versuchen, auf dieselbe Ressource zuzugreifen. In sicherheitskritischen Anwendungen geht es vor allem darum, wie eine auf einem Kern ausgeführte Anwendung durch einen solchen Konflikt mit gemeinsam genutzten Ressourcen eine auf einem anderen Kern ausgeführte Anwendung beeinträchtigen kann, was sich negativ auf den Determinismus, die Dienstequalität und letztendlich die Sicherheit auswirkt.

Die Auswirkungen von Konflikten mit gemeinsam genutzten Ressourcen können ziemlich groß sein, sofern sie nicht entschärft werden. In einem Quad-Core-Prozessor, in dem die Kerne nur über chipinterne Verbindungen ohne I/O-Zugriff auf DDR-Speicher zugreifen, haben mehrere Störquellen von mehreren Kernen die Worst-Case-Ausführungszeit (worst-case execution time; WCET) um den Faktor 12 erhöht. Aufgrund von Arbitrierungs- und Planungsalgorithmen für gemeinsam genutzte Ressourcen im DDR-Controller kann eine gerechte Aufteilung daher nicht garantiert werden, und die Auswirkungen einer gegenseitigen Beeinflussung sind häufig nicht linear. Tests zeigen, dass ein einzelner störender Kern die WCET auf einem anderen Kern um den Faktor 8 erhöhen kann. Folglich kann eine Anwendung mit niedrigerer Priorität oder Kritikalität verhindern, dass eine Anwendung mit höherer Priorität oder Kritikalität ihre beabsichtigte Funktion ausführt.

Verschiedene Maßnahmen vereinfachen heute die sicherheitskritische Implementierung von Multicore-Prozessoren. Standards wurden aktualisiert, um Multicore-Probleme zu beheben, wie z.B. ARINC 653, der die räumliche und zeitliche Partitionierung von Echtzeit-Betriebssystemen (RTOS, real-time operating system) für sicherheitskritische Avionik-Anwendungen abdeckt. ARINC 653 wurde 2015 aktualisiert (ARINC 653 Teil 1, Anhang 4), um den Multicore-Betrieb für einzelne Anwendungen zu regeln, die als „Partitionen“ bezeichnet werden.

Der technische Standard FACE (Future Airborne Capability Environment) der Open Group, Version 3.0, regelt Multicore-Support, indem Compliance zum Anhang 4 verlangt wird. Das von der FAA, EASA, TCCA und anderen Luftfahrtbehörden unterstützte Certification Authority Software Team (CAST) hat ein Positionspapier mit Leitlinien für Multicore-Systeme namens CAST-32A veröffentlicht. Zusammen bilden diese Dokumente die Voraussetzungen für den erfolgreichen Einsatz von Multicore-Lösungen für Anwendungen, die nach DAL A zertifiziert werden können – dem höchsten RTCA/DO-178C Design- Assurance-Level (DAL) für sicherheitskritische Software.

Partitionierung von Raum und Zeit erhöht die Sicherheit

In einem Single-Core-Prozessor lassen sich mehrere sicherheitskritische Anwendungen auf demselben Prozessor ausführen, indem der Speicherplatz und die Prozessorzeit zuverlässig zwischen diesen aufgeteilt werden. Durch die Speicherplatz-Partitionierung wird jede Anwendung, die zu einem bestimmten Zeitpunkt ausgeführt wird, ein nicht überlappender Speicherabschnitt zugewiesen, der von der Speicherverwaltungseinheit (MMU, Memory Management Unit) des Prozessors erzwungen wird.

Die Zeitaufteilung unterteilt ein festes Zeitintervall (Haupt-Frame) in eine Folge fester Teilintervalle, die als Partitionszeitfenster bezeichnet werden. Jeder Anwendung werden ein oder mehrere Partitionszeitfenster zugewiesen, wobei die Länge und Anzahl der Fenster von der Ausführungszeit im ungünstigsten Fall (WCET) und der erforderlichen Wiederholrate der Anwendung abhängen. Das Betriebssystem (OS, operating system) stellt sicher, dass jede Anwendung während der zugewiesenen Zeit Zugriff auf den Prozessorkern erhält. Um diese sicherheitskritischen Techniken auf Multicore-Prozessoren anzuwenden, sind mehrere komplexe Herausforderungen zu bewältigen. Die schwierigste ist die Störung zwischen Kernen über die gemeinsam genutzten Ressourcen.

Interferenzen zwischen den Kernen behandeln

CAST-32A bietet Zertifizierungsrichtlinien, um Störungen in Multicore-Prozessoren zu beheben. Ein Ansatz besteht darin, einen speziellen Anwendungsfall zu erstellen, der auf dem Testen und Analysieren von WCET für jede Anwendung/Partition und deren Worst-Case-Auslastung gemeinsam genutzter Ressourcen basiert. Spezielle Lösungen können jedoch dazu führen, dass das gesamte System mit der Änderung einer einzelnen Anwendung/Partition gesperrt und neu verifiziert wird. Dies stellt ein erhebliches Hindernis für das Implementieren und Aufrechterhalten eines integrierten modularen Avioniksystems (IMA) dar. Ohne Betriebssystem-Mechanismen und Werkzeuge zur Minderung von Störungen sind die Kosten und Risiken für das Aufrechterhalten sehr hoch. Änderungen an einer Anwendung erfordern dann eine erneute vollständige WCET-Validierung für alle integrierten Anwendungen.

Der bessere Ansatz ist, dass das OS Störungen effektiv verwaltet – basierend auf der Verfügbarkeit von DAL-A-Laufzeitmechanismen, Bibliotheken und Werkzeugen, die den CAST-32A-Vorgaben entsprechen. Dieser Ansatz bietet dem Systemintegrator eine effektive und flexible Lösung. Es vereinfacht auch das Hinzufügen neuer Anwendungen ohne größere Änderungen an der Systemarchitektur, reduziert die Aktivitäten zur erneuten Überprüfung und hilft, die Sperre des OEM-Anbieters zu beseitigen.

Effektive Nutzung von Multicore-Ressourcen

Um den Durchsatz und die SWaP-Vorteile (software as a product) von Multicore-Lösungen zu nutzen, muss die Softwarearchitektur eine hohe Auslastung der verfügbaren Prozessorkernen unterstützen. Alle Multicore-Funktionen müssen unterstützt werden – von der gleichzeitigen Nutzung aller Kerne (im Gegensatz zu verfügbaren Kernen, die beim Start in den Ruhezustand versetzt oder zurückgesetzt werden) bis hin zur Bereitstellung eines Mechanismus für den deterministischen Lastausgleich. Je flexibler die Software-Multiprozessor-Architektur ist, desto mehr Werkzeuge muss der Entwickler einsetzen, um eine hohe Auslastung zu erzielen.

Bild 1: Separate Prozessorkerne (grau dargestellt) teilen sich viele Ressourcen wie Interconnects, Speicher-Controller und I/Os.
Bild 1: Separate Prozessorkerne (grau dargestellt) teilen sich viele Ressourcen wie Interconnects, Speicher-Controller und I/Os. (Bild: Green Hills Software)

Architekturen für Software-Multi-Processing

Wie bei Multiprozessor-Systemen kann die Softwarearchitektur von Multicore-Prozessoren danach klassifiziert werden, wie auf Speicher von anderen Prozessoren oder Kernen zugegriffen wird und ob jeder Prozessor oder Kern eine eigene Kopie des Betriebssystems ausführt. Die einfachste Softwarearchitektur für ein Multicore-basiertes System ist Asymmetric Multi-Processing (AMP), bei dem jeder Core unabhängig ausgeführt wird und jeweils ein eigenes Betriebssystem oder ein Gastbetriebssystem auf einem Hypervisor installiert ist. Jeder Kern führt eine andere Anwendung aus, wobei die Koordination zwischen den Kernen hinsichtlich der Planung gering ist. Diese Entkopplung kann zu einer unzureichenden Auslastung führen, da der Lastausgleich fehlt, Probleme bei der Minderung von Konflikten mit gemeinsam genutzten Ressourcen auftreten und keine koordinierten Aktivitäten zwischen Kernen durchgeführt werden können, wie sie für umfassende integrierte Tests nötig sind.

Die moderne Alternative ist Symmetric Multi-Processing (SMP). Hier kontrolliert ein einziges OS alle Ressourcen, einschließlich welche Anwendungs-Threads auf welchen Kernen ausgeführt werden. Diese Architektur ist leicht zu programmieren, da alle Kerne „symmetrisch“ auf Ressourcen zugreifen, sodass das Betriebssystem jedem Kern einen beliebigen Thread zuweisen kann.

Nicht zu wissen, welche Threads auf welchen Kernen laufen, ist eine große Herausforderung und ein Risiko für den deterministischen Betrieb in kritischen Systemen. Als Lösung verweist CAST-32A auf Bound Multi-Processing (BMP). Diese erweiterte und eingeschränkte Form von SMP bindet die Aufgaben einer Anwendung statisch an bestimmte Kerne, sodass der Systementwickler den gleichzeitigen Betrieb mehrerer Kerne genau steuern kann. BMP folgt direkt der Multicore-Anforderung in ARINC 653 (Anhang 4, Abschnitt 2.2.1), in dem es heißt: „Mehrere Prozesse innerhalb einer Partition sollen gleichzeitig auf verschiedenen Prozessorkernen ausgeführt werden.“ Das heißt, die Architektur es einer Multithread-Anwendung muss es ermöglichen, über mehrere Prozessorkerne hinweg parallel zu laufen.

Ein Multicore-RTOS für die Sicherheitszertifizierung

Bild 2: Ausführung von AMP-, SMP- und BMP-Anwendungen in zwei unterschiedlichen Fenstern eines zeitpartitionierten Kernels.
Bild 2: Ausführung von AMP-, SMP- und BMP-Anwendungen in zwei unterschiedlichen Fenstern eines zeitpartitionierten Kernels. (Bild: Green Hills Software)

Green Hills‘ INTEGRITY-178 tuMP ist ein einheitliches Multicore-Echtzeitbetriebssystem, das eine gleichzeitige Kombinationen von AMP, SMP und BMP unterstützt. Der tuMP-Ansatz (time-variant unified Multi-Processing) des RTOS bietet maximale Flexibilität beim Portieren, Erweitern und Optimieren betriebs- und datensicherheitskritischer (Safety & Security) Anwendungen auf eine Multicore-Architektur.

Es beginnt mit einem zeitpartitionierten Kernel, der auf allen Kernen ausgeführt wird. Auf diese Weise wird ermöglicht, eine beliebige Kombination von AMP-, SMP- und BMP-Anwendungen an einen Kern oder Gruppen von Kernen zu binden (Bild 2). Diese Gruppen werden als Affinitätsgruppen bezeichnet. Anschließend wird eine Zeitvarianz hinzugefügt, sodass die Partitionszeitfenster nicht über mehrere Kerne hinweg ausgerichtet werden müssen.

INTEGRITY-178 tuMP enthält außerdem eine Bandbreitenzuweisung/-überwachung (Bandwidth Allocation and Monitoring; BAM), die für DO-178C DAL A entwickelt wurde. Diese BAM überwacht und erzwingt die Bandbreitenzuweisung der chipinternen Verbindungen zu jedem der Kerne. Da sich die Verbindung auf Chipebene im Zentrum der Interaktionen zwischen den Kernen und anderen gemeinsam genutzten Ressourcen befindet, ist sie der ideale Ort, um Grenzen für die Nutzung gemeinsam genutzter Ressourcen zu überwachen und durchzusetzen.

Bild 3: Beispiel einer Zuweisung der anteilsmäßigen Bandbreite auf die einzelnen Prozessorkerne.
Bild 3: Beispiel einer Zuweisung der anteilsmäßigen Bandbreite auf die einzelnen Prozessorkerne. (Bild: Green Hills Software)

Der Systementwickler entscheidet anhand der DALs (Design Assurance Levels) oder den funktionalen Anforderungen der Anwendung, wie viel Bandbreite jedem Kern zugewiesen werden soll. Wenn Anwendungen auf einem bestimmten Kern die Schwellenbandbreite für ein bestimmtes BAM-Zeitquantum erreichen, wird dieser vom Verbrauch gemeinsam genutzter Ressourcen bis zum nächsten BAM-Zeitquantum abgeschnitten. Damit kann einer DAL-A-Anwendung, die auf Kern 0 ausgeführt wird, eine festgelegte Menge an Ressourcen zugewiesen werden, z.B. 60% der Gesamtbandbreite, während den anderen drei Kernen nur jeweils 15, 15 und 10% zugewiesen werden (Bild 3).

Das INTEGRITY-178 tuMP RTOS ermöglicht es, mehrere unabhängige Anwendungen in einer Multicore-Umgebung vorhersehbar, mit überwachten Grenzen und anwendungsunabhängig auszuführen. Durch seine BAM-Funktion können Systemintegratoren Störungen in Multicore-Systemen erkennen und minimieren. Durch die Einhaltung der CAST-32A-Richtlinien für Multicore-Störungen verringert BAM das Integrations- und Zertifizierungsrisiko erheblich. Zusammen ermöglichen BAM und die flexible Multiprozessarchitektur von INTEGRITY-178 tuMP, die SWaP-Ziele zu erreichen, indem sie eine optimale Auslastung der Kerne ermöglichen und gleichzeitig den für sicherheitskritische Anwendungen erforderlichen Determinismus beibehalten.

Software für Multicore-Systeme entwickeln

Software für Multicore-Systeme entwickeln

15.10.19 - Multiprozess- und Multiprozessor-Applikationen zählen seit vielen Jahren zur Standardausstattung von Embedded Systemen. Dank der parallelen Verarbeitung lassen sich kürzere Reaktionszeiten erreichen und komplexere Aufgaben bewältigen. Was bedeutet das für die Entwicklung und die Architektur von Embedded Systemen? lesen

Zertifizierung: Ein Ansatz für ein modernes funktionales Sicherheitskonzept

Zertifizierung: Ein Ansatz für ein modernes funktionales Sicherheitskonzept

08.04.19 - Kann ein nicht-zertifizierter SoC in einer Sicherheitsanwendung zum Einsatz kommen? Der Beitrag deckt wichtige Architektur- und Design-Abwägungen moderner Sicherheitseinrichtungen ab. lesen

Echtzeit in Multicore-Designs braucht eine neue OS-Denkweise

Echtzeit in Multicore-Designs braucht eine neue OS-Denkweise

29.08.18 - Seitenkanalattacken oder unentdeckte Hardware-Sicherheitslücken sind wie Tretminen für die System-Security. Wie bleibt das OS sicher? Ein Umdenken bei der Betriebssystem-Implementierung ist gefragt. lesen

Dieser Beitrag ist erschienen in der Fachzeitschrift ELEKTRONIKPRAXIS Ausgabe 22/2019 (Download PDF)

* Richard Jaenicke ist Director of Product Marketing bei Green Hills Software.

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 46188659 / Embedded Betriebssysteme)