Multicore-SoCs Große Computerleistung bedingt große Softwareverantwortung

Anbieter zum Thema

Parasoft® Deutschland GmbH

RTI Real-Time Innovations

CADFEM Germany GmbH

Siemens Industry Software GmbH

Die jüngsten Halbleiterinnovationen haben zur Entwicklung von Multicore-SoCs (Systems on Chip) geführt. Um den technologischen Fortschritt an der Hardwarefront zu nutzen, benötigen Embedded-Entwickler jetzt optimale Software-Tools und -Verfahren. Ein umfassendes Verständnis der verschiedenen verfügbaren Multicore-Designoptionen ermöglicht es den Entwicklern, die SoCs in vollem Umfang zu nutzen.

Eine effektive Verwaltung und nahtlose Orchestrierung verschiedener Softwarekomponenten auf einem einzigen SoC kann auf vielfältige Weise erreicht werden. Hypervisoren und Multicore-Frameworks sind die beiden Hauptoptionen zur Verwaltung mehrerer Prozessoren, die auf demselben [(Chip/Gerät)] laufen. Beide haben ihre jeweiligen Vor- und Nachteile.

In diesem Artikel werden die verschiedenen Strukturen und Funktionen untersucht, einschließlich Systeme mit gemischter Sicherheitskritikalität. Mit diesen Informationen können Softwareingenieure ihre Anwendungsfälle bewerten und eine Entscheidung treffen - Hypervisor oder Multicore-Framework? Müssen sie überhaupt wählen?

SoCs mit mehreren Prozessoren

Wie der Name schon sagt, können diese passend benannten Systeme auf Chips (SoCs) ganze Systeme beherbergen, indem sie mehrere Prozessorkerne auf einer einzigen Hardware unterbringen. Das wahre Potenzial dieser technologischen Innovation liegt in der hervorstechenden Eigenschaft, dass diese multiplen Kerne nicht gleich, d. h. homogen sein müssen. Heterogenes Multiprocessing ermöglicht die Konsolidierung verschiedener Systeme, die in der Vergangenheit unterschiedliche Geräte oder unterschiedliche Systeme auf verschiedenen Geräten erforderten. Die Nützlichkeit von SoCs geht jedoch über die reine Konsolidierung von Systemen hinaus.

Damit rückt das Konzept der gemischten Sicherheitskritikalität in den Mittelpunkt. Ein System mit gemischter Sicherheitskritikalität ist ein System, bei dem sowohl eine sichere Domäne als auch eine nicht sichere Domäne auf einem einzigen SoC ausgeführt werden. Es sollte nicht überraschen, dass die Multicore-Verarbeitung im Bereich der eingebetteten Systeme immer beliebter wird (Abbildung 1).

Wie bei den meisten Dingen im Leben geht jedoch mit großer (Rechen-)Leistung auch große (Software- und Hardware-)Verantwortung einher. So leistungsfähig Multiprocessing auch sein mag, es bringt auch eine Reihe von Herausforderungen mit sich. Die bereits erwähnte gemischte Sicherheitskritikalität kann eine Kombination von unternehmenskritischen Teilsystemen mit Echtzeit-/Determinismusanforderungen, sicheren Teilsystemen und sicherheitszertifizierten Teilsystemen umfassen. Die Gewährleistung der gleichen Softwarequalität und -sicherheit bei der Integration verschiedener Funktionen in ein einziges SoC kann eine Herausforderung sein. Dies erfordert die Isolierung sicherer und nicht sicherer Domänen und die Einrichtung einer zuverlässigen sicheren Kommunikation zwischen den verschiedenen Domänen.

Die Isolierung kann je nach sicherheitskritischen Anwendungen unterschiedliche Formen annehmen:

• Physikalische und zeitliche Isolierung erfordert eigene unabhängige Kerne

• Räumliche Isolierung erfordert Hardware-Schutzeinheiten

• Systemweite räumliche Isolierung erfordert direkten Speicherzugriff (DMA) und erhebliche Leistung

Weitere Herausforderungen bei der heterogenen Multiprozessorverarbeitung sind:

Auslastung - Wie können die im System vorhandenen heterogenen Rechenressourcen effizient genutzt werden?

Trennung - Wie lässt sich das erforderliche Maß an Sicherheitstrennung zwischen verschiedenen Softwarefunktionalitäten erreichen?

Gemeinsame Nutzung von Ressourcen - Wie lassen sich Systemressourcen über konsolidierte Systemfunktionen hinweg effektiv gemeinsam nutzen?

Boot-Reihenfolge – In welcher Reihenfolge wird die Software auf den einzelnen Kernen gestartet, sodass Synchronisierungs- und Sicherheitsprobleme vermieden werden.

Angesichts der Komplexität dieser Systeme ist eine sorgfältige Zuweisung, Trennung und Nutzung der Ressourcen erforderlich. Es gibt zwei Hauptlösungen für dieses Problem: Hypervisoren und Multicore-Frameworks. Aber was sind das für Lösungen? Ist eine von ihnen (oder beide) die richtige? Dies gilt es herauszufinden.

Hier sind einige Details, die helfen können, eine fundierte Entscheidung für einen speziellen Anwendungsfall zu treffen.

Hypervisoren

Ein Hypervisor ist eine sehr komplexe, vielseitige Softwarekomponente, die mehrere Betriebssysteme überwacht und den Zugriff auf Prozessorkerne und auf Peripheriegeräte, die Kommunikation zwischen Betriebssystemen und die Sicherheit zwischen Betriebssystemen verwaltet.

Alternativ können Hypervisoren in eingebetteten Anwendungen in asymmetrischen Multicore-Processing (AMP)-Designs eingesetzt werden, die die Überwachung der Kommunikation zwischen den Kernen und die Bereitstellung von Peripheriegeräten für bestimmte Kerne erfordern (Abbildung 2).

Ein Hypervisor kann auch die Boot-Sequenz übernehmen und den gemeinsamen Zugriff auf Peripheriegeräte verwalten. Der Hauptvorteil eines Hypervisors besteht darin, dass bei einem Absturz des Betriebssystems die Ausführung von Arbeitslasten auf anderen Kernen nicht beeinträchtigt wird; der Hypervisor kann sogar das Betriebssystem neu starten, ohne dass ein Neustart des Geräts erforderlich ist.

Es ist ratsam, einen Hypervisor zu verwenden, der speziell für eingebettete Anwendungen entwickelt wurde, um eine bessere Leistung zu gewährleisten.

Hypervisoren sind heute so konzipiert, dass sie die zugrunde liegenden Hardware-Virtualisierungsfunktionen der meisten Multicore-Prozessoren nutzen. Dies ermöglicht die Verwendung eines unveränderten Gastbetriebssystems, das mit dem Hypervisor ausgeführt wird

Wie jede andere Technologie haben auch Hypervisoren Vor- und Nachteile (Tabelle 1).

Multicore-Frameworks

Aufgrund ihrer Fähigkeiten zur Trennung, Verwaltung und gemeinsamen Nutzung bieten Hypervisoren mehr Funktionen, als viele eingebettete Designs benötigen - sie können zu viel des Guten sein. Daher haben einige Anbieter von Embedded-Runtime-Systemen eine Alternative entwickelt, die speziell für die Unterstützung eines AMP-Multicore-Systems konzipiert wurde: das Multicore-Framework.

Multicore-Frameworks sind speziell auf die Unterstützung von Multicore-Anwendungen ausgelegt und bieten nur die kritischen Funktionen: Steuerung der Boot-Reihenfolge und Kommunikation zwischen den Kernen (Abbildung 3). Das Framework lädt ein System mit viel weniger Overhead und kann auf einfacheren Systemen als Hypervisoren laufen. Obwohl jeder Kern in einem AMP-Design wahrscheinlich ein Betriebssystem betreibt, kann es einen oder mehrere Bare-Metal-Kerne geben (d. h. sie laufen ohne Betriebssystem).

Multicore-Frameworks haben, ähnlich wie Hypervisoren, ihre Vor- und Nachteile (Tabelle 2).

Gemischte sicherheitskritische Systeme

Ein SoC für ein eingebettetes Softwaremodul muss sowohl sicherheitskritische als auch nicht sicherheitskritische Funktionen verarbeiten. Denken Sie zum Beispiel an ein Auto, dessen Navigationssystem und Radioeinstellungen auf demselben SoC laufen. Eine Funktion ist sicherheitskritisch, die andere höchstwahrscheinlich nicht. Die Herausforderung besteht darin, dafür zu sorgen, dass die Navigation auch dann weiterläuft, wenn das Radio ausfällt.

Ein System mit gemischter Sicherheitskritikalität erfordert die Ausführung mehrerer Anwendungen mit unterschiedlichen Sicherheitsintegritätsstufen (SILs) oder unterschiedlichen Kritikalitäten (sicherheitskritisch und nicht sicherheitskritisch) auf einem einzigen SoC. Sowohl ein Hypervisor als auch ein Multicore-Framework können diese Art von Konfiguration unterstützen.

Unterschiedliche Sicherheitsniveaus erfordern eine Zertifizierung auf der Grundlage verschiedener Industriestandards. Die virtuellen Maschinen können dann mit dem zertifizierten Hypervisor auf unterschiedlichen Kritikalitätsstufen laufen. Der zertifizierte Hypervisor bietet eine Trennung, die in der Regel zugrunde liegende Hardware-Virtualisierungs- und Separationsfunktionen auf dem SoC verwendet; dies ist jedoch mit zusätzlichen Zertifizierungskosten für die Zertifizierung des zusätzlichen Separationscodes verbunden.

Ein Multicore-Framework nutzt andere hardwaregestützte Trennungsfunktionen, die von einigen SoC-Architekturen bereitgestellt werden, um die erforderliche Trennung zwischen der sicheren Domäne und der nicht sicheren Domäne zu erreichen (Abbildung 4). Dies umfasst die Trennung von Verarbeitungsblöcken, Speicherblöcken, Peripheriegeräten und Systemfunktionen. Das Multicore Framework bietet erweiterte gebundene Überprüfungen, um die Integrität von gemeinsam genutzten Speicherdatenstrukturen sicherzustellen, sowie Interrupt-Drosseln und Polling-Modus, um Interrupt-Flooding zu verhindern.

Ein gemeinsames Merkmal solcher Systeme besteht darin, dass die Behörden eine Zertifizierung des sicheren Teilsystems/Teilbereichs verlangen, bevor sie vermarktet oder eingesetzt werden können. Der Zertifizierungsprozess kann sich von Branche zu Branche unterscheiden, und das Verfahren kann sowohl kosten- als auch zeitintensiv sein. Alles, was diese Kosten und den Zeitaufwand reduzieren kann, ist ein Segen.

Die Kosten und der Zeitaufwand für die Zertifizierung werden durch das Volumen des Codes erheblich beeinflusst. Daher ist es hilfreich, die Codelänge zu minimieren. Dies wirkt sich auch auf die Wahl des Betriebssystems aus. Da der Quellcode sofort verfügbar ist, ist ein kleines RTOS, wie Nucleus RTOS, eine attraktive Option. Normalerweise ist es nicht möglich, ein Betriebssystem allein zertifizieren zu lassen, da die gesamte Anwendung dem Prozess unterliegen muss. Siemens Embedded Nucleus SafetyCert kann jedoch ein zertifiziertes Paket mit Artefakten und Testfällen für das RTOS sowie ein „Vor-Zertifizierungs“-Paket anbieten, um den Prozess zu vereinfachen.

Anwendungen mit gemischter Sicherheitskritikalität werden in der Regel auf Single-Core-Systemen entwickelt. Die Verwendung eines Multicore-Systems erleichtert jedoch den Zertifizierungsprozess, da nur das Teilsystem mit den kritischen Funktionen zertifiziert wird, während die restlichen CPUs andere nicht kritische Funktionen ausführen.

Es ist möglich, nur dieses Teilsystem zu zertifizieren, solange es einen genehmigten gesicherten ausführbaren Bereich gibt. Beispielsweise verwendet Xilinx Zynq UltraScale+ MPSoC die Xilinx Speicherschutzeinheit (XMPU) und die Xilinx Peripherieschutzeinheit (XPPU), um eine Trennung zwischen zertifizierten und nicht zertifizierten Teilen des Systems zu schaffen. Ein weiteres Beispiel hierfür können die SoCs der NXP i.MX 8-Serie sein, die einen Resource Domain Controller (RDC) zwischen den zertifizierten und den nicht zertifizierten Teilen des Systems verwenden.

Auf diese Weise kann sogar ein nicht sicherheitszertifizierter Hypervisor zusammen mit einem gemischt sicherheitskritischen Multicore-Framework verwendet werden.

In der Vergangenheit mussten Anwender verschiedene Hardwaresysteme erstellen oder das gesamte System zertifizieren (einschließlich der Teile, die für die Sicherheitsfunktionen nicht relevant waren), um die Anforderungen an die funktionale Sicherheit zu erfüllen. Jetzt können die heterogenen Multicore-SoC-Funktionen genutzt werden, um den sicheren Bereich vom unsicheren zu trennen und die Kommunikation über ein zertifiziertes Framework aufzubauen. Dies senkt die Kosten für Hardware und Zertifizierung.

Die Gewährleistung einer sicheren Kommunikation kann auf zwei Arten erfolgen:

Puffervalidierung - Pufferparameter wie Adresse, Größe und Berechtigungen müssen validiert werden, bevor sie von der sicheren Domäne verwendet werden, einschließlich der Überprüfung der Grenzen des Puffers und des Verwerfens von Puffern, die außerhalb des gültigen Bereichs liegen. Die Puffervalidierung muss mit der richtigen Fehlerreaktion gekoppelt werden, um einen Einblick in die Systeminteraktionen zu erhalten und schädliche Aktivitäten zu erkennen.

Abschwächung von Interrupt-Flooding - Die unsichere Welt hat das Potenzial, den Kommunikationskanal mit Unterbrechungen zu überfluten. Diese unvorhergesehene Last könnte die zeitlichen Isolationsanforderungen des Systems verletzen, wenn keine spezielle Behandlung vorgesehen ist. Häufig ist die Implementierung eines Mechanismus erforderlich, um übermäßige Unterbrechungen von der nicht sicheren Seite aus zu drosseln oder den Polling-Modus auf der sicheren Seite zu unterstützen.

Wie sollte der Entwickler auswählen?

Ein Gerät oder Instrument ist nur so leistungsfähig wie die Fähigkeit der Person, die es bedient. Um das SoC effektiv umzusetzen, müssen strategische Entscheidungen sowohl in Bezug auf die Hardware als auch auf die Software getroffen werden. Die Entscheidung, ein Design mit mehreren Prozessoren auszuführen, kann durch mehrere Faktoren beeinflusst werden: technische Ziele, Time-to-Market, Zieldesign und Produktionskosten.

Die Entscheidung, zur Steuerung und Verwaltung eines Multicore-Systems einen Hypervisor oder ein Multicore-Framework oder beides (Abbildung 6) zu nutzen, ist eine wichtige Architekturentscheidung.

Die Wahl hängt letztlich von den spezifischen Anwendungsanforderungen und dem Anwendungsfall des Systems ab. Die Optionen sollten als ergänzende Lösungen betrachtet werden, um die Leistungsfähigkeit eines Multicore-SoC zu erschließen. Die Verfügbarkeit und das Verständnis dieser Auswahlmöglichkeiten ermöglichen es dem Entwickler, ein optimaleres Multicore-Design zu erstellen.

* Jeff Hancock ist bei Siemens Digital Industries Software für die Produktlinien Nucleus RTOS, Multicore Framework und Nucleus Hypervisor sowie die dazugehörige Middleware und Professional Services zuständig.

(ID:48488335)