Multicore-Determinismus für sicherheitskritische Anwendungen

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.

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Parasoft® Deutschland GmbH

RTI Real-Time Innovations

Green Hills Software, Inc

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.

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

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.

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

Zertifizierung: Ein Ansatz für ein modernes funktionales Sicherheitskonzept

Echtzeit in Multicore-Designs braucht eine neue OS-Denkweise

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

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

(ID:46188659)