Multicore

Sicherheit auf allen Kernen

Seite: 2/3

Firma zum Thema

Anforderungen an Sicherheitsarchitekturen aus der Normenwelt

Die Entwicklung sicherheitskritischer Systeme unterliegt sehr stark den gesetzlichen Normen. Prominente Vertreter solcher Normen sind z.B. die ISO26262 [1] in der Automobilwelt oder die ISO13849 [2] in der Maschinewelt, auf die sich im Folgenden bezogen wird.

Bei der Entwicklung der Steuerung wird nach [3] ein Entwicklungsprozess empfohlen, der die folgenden Schritte enthält:

Bildergalerie
Bildergalerie mit 6 Bildern
  • Risikoanalyse und -beurteilung
  • Identifikation der notwendigen Sicherheitsfunktionen zur Reduzierung des Risikos und Ermittlung des erforderlichen Performance Levels
  • Festlegung der Steuerungsarchitektur
  • Bewertung der Auswirkung von Fehlern und Diagnosemöglichkeiten, Fehlervermeidung
  • Umsetzung fehlervermeidender Maßnahmen im Softwarelebenszyklus
  • Verifikation und Validierung des Gesamtsystems

Aufgrund der möglichen Gefährdungen für die Nutzer eines Gabelstaplers soll die Steuerung für Fahr- und Hebeaktionen dem Performance Level d genügen. Gemäß des Bild 3 in der Bildergalerie lässt sich erkennen, dass sich der gewünschte Performance Level d mit einer Architektur der Kategorie 2 oder 3 erreichen lässt. Bei einer Kategorie 2 Architektur gelten allerdings höhere Anforderungen an den Diagnosedeckungsgrad.

Bezüglich der Hardwarearchitektur unterscheidet die Norm folgende Kategorien: siehe Tabelle 1 der Bildergalerie.

Übertragung der Architekturkategorien auf einen Multicore Controller

Betrachtet man die unterschiedlichen Kategorien aus Tabelle 1, so lässt sich die Struktur eines Multicore Controllers nicht direkt in diese Kategorien übersetzen. Zwar verfügt ein Multicore Controller über unabhängige Rechenkerne, doch der Speicher und auch die Peripheriebausteine können von allen Kernen angesprochen werden.

Zusätzliche Technologien wie Memory Protection Units versprechen hier zwar bei korrekter Konfiguration eine gewisse Separierung, die den Anforderungen der Norm in Bezug auf Maßnahmen gegen Common Cause Fehler aber sehr wahrscheinlich nicht genügen, vor allem die Aspekte Trennung/Abtrennung der Signalpfade, Diversität der Bauteile und Auswirkung von Umweltstörungen erscheinen hier problematisch.

Unabhängig von dieser in Zukunft sicherlich noch zu beantwortenden Frage muss für die Softwarearchitektur gelten, dass ein möglichst hoher Grad an Rückwirkungsfreiheit (Freedom of Interferance) zwischen den einzelnen Applikationen und hier insbesondere zwischen den Logikfunktionen und den Sicherheitsfunktionen zu gewährleisten ist, der sich wie folgt begründet:

  • Die Qualifikation kleinerer Softwareeinheiten mit klaren Schnittstellen ist einfacher und sicherer, als die Qualifikation großer Software-Monolithen. Gerade regelungstechnische Applikationen realisieren den Datenaustausch häufig gerne mithilfe globaler Variablen, deren Datenfluss in der Praxis nur schwer oder gar nicht zu verifizieren ist.
  • Die Auswirkung möglicher (Software)-Fehler wird lokal begrenzt.
  • Sicherheitsfunktionen und normale Funktionen müssen unterschiedlich qualifiziert werden. Eine klare und sichere Trennung ermöglicht es, die Sicherheitsfunktionen und den Applikationsteil einmal nach den jeweiligen Prozessanforderungen zu qualifizieren. Insbesondere bei Änderungen im applikativen Teil der Software kann dieser mit weniger Aufwand requalifiziert werden.

Der Aurix-Microcontroller unterstützt die Anforderung nach „Freedom from Interferance“ sowohl zwischen Software Komponenten untereinander als auch zwischen Software Komponenten und Peripherieregistern. Hierbei werden die Datendomäne, die Zeitdomäne und die Ressourcendomäne unterschieden.

Für den Schutz der Datendomäne (Speicher) wird primär die Memory Protection Unit (MPU) des Aurix verwendet. Zusätzlich steht mit der Bus Memory Protection Unit (BUS-MPU) ein weiteres Instrument zur Verfügung. Während die MPU vom jeweils zugreifenden Prozess angesteuert wird (Task xyz soll auf den Speicherbereich abc zugreifen) und eher dynamisch verwendet werden kann, wird die BUS-MPU aus Sicht der zugegriffenen Ressource konfiguriert (auf den Speicherbereich abc dürfen nur bestimmte Bus-Teilnehmer, z.B. Tasks von einem bestimmten Core zugreifen) und realisiert eher statische Einschränkungen.

Die Zeitdomäne wird primär durch die nebenläufige Ausführung des Codes auf den einzelnen Kernen realisiert. Sobald ein Kern gestartet ist, läuft er unabhängig von den anderen Kernen, solange zumindest keine Spinlocks oder andere blockierende Konstrukte genutzt werden. Zur Absicherung des Laufzeitverhaltens stehen außerdem die üblichen Watchdogs für lokale und ein Safety Watchdog für globale Operationen zur Verfügung.

Der Schutz der Peripherieregister erfolgt ähnlich wie der Speicherschutz über die Memory Protection Unit bzw. die Register Access Protection (RAP, funktional vergleichbar der BUS-MPU). Da die MPU 8 byte aligned ist, können damit nur komplette Module gesichert werden, für einzelne Pins reicht die Granularität häufig nicht. Die RAP bezieht sich immer auf komplette Peripheriemodule und erlaubt keine weitere Unterteilung. Diese Einschränkungen sind beim Hardwarelayout zu berücksichtigen. Darüber hinaus stehen neben dem Supervisor Mode zwei Usermodes zur Verfügung, die den Zugriff auf die Peripherie beschränken.

Basissoftware / Betriebssystem PxROS

Nach dem Booten des Aurix sind alle Sicherheitsmechanismen deaktiviert. D.h. die Applikation muss den Zugriff bewusst einschränken, um bestimmte Ressourcen zu schützen. Da diese Konfiguration aus naheliegenden Gründen nicht über die Applikation erfolgen soll, wurde das Betriebssystem PxROS der Firma HighTec ausgewählt. Bei PxROS handelt es sich um ein zertifiziertes Multicore Betriebssystem, das die Hardwarefeatures des Aurix optimal unterstützt:

  • Einzelne Tasks können dynamisch verschiedenen Cores zugewiesen werden.
  • Die Taskkonfiguration enthält sämtliche Zugriffsrechte auf Speicher und Peripherie, die damit automatisch für die Applikationssoftware gelten, die im Kontext dieses Tasks ausgeführt wird.
  • Der Datenaustausch zwischen den Tasks erfolgt über non-blocking Events und Messages. Dieses erfolgt unabhängig vom Core, auf dem der Task physikalisch läuft. D.h. die Zuordnung der Tasks auf die Hardware kann rekonfiguriert werden, ohne dass der Applikationscode geändert werden muss.

(ID:44288508)