Der Blätterkatalog benötigt Javascript.
Bitte aktivieren Sie Javascript in Ihren Browser-Einstellungen.
The Blätterkatalog requires Javascript.
Please activate Javascript in your browser settings.
DESIGN ELEKTRONIK 03 2023 39 www designelektronik de Tests können Entwickler mithilfe eines Hardware-Debuggers unterstützen um – wie es die ISO26262 empfiehlt – so nah wie möglich an der realen Hardware zu testen Verschiedene Anforderungen in einer ECU Heutige Hochleistungs-ECUs implementieren in der Regel nicht nur eine Art von Anwendung sondern mehrere Diese können unterschiedliche Stufen der funktionalen Sicherheit haben Zum Beispiel kann eine ECU neben einer ASIL-D-Applikation ebenfalls eine Quality-Management QM - Level-Applikation implementieren Quality-Management also ohne besondere Anforderungen an die funktionale Sicherheit Was bedeutet das für das Entwickeln der Software? In dem Fall gibt es zwei Möglichkeiten die Anforderungen der ISO26262-Norm zu erfüllen Entweder werden alle Komponenten so behandelt als ob sie die höchsten ASIL-Anforderungen erfüllen müssten oder es ist Störungsfreiheit FFI Freedom from Interference zu garantieren Das bedeutet es muss sichergestellt sein dass der QM-Teil den ASIL-Teil in derselben ECU nicht stören kann Bild 1 Hierzu muss zum einen die FFI in Bezug auf die Speichernutzung gewährleistet sein Also darf der QM-Teil nicht in der Lage sein den Speicher zu beschädigen der einem ASIL-Teil zugewiesen ist Der zweite Aspekt ist Timing Execution Hier ist beispielsweise zu gewährleisten dass das Ausführen einer QM-Software nicht das Ausführen einer ASIL-Software blockieren kann Der dritte Aspekt Informationsaustausch bezieht sich auf eine gestörte Datenkommunikation zwischen einem Sender und einem Empfänger zum Beispiel durch Einfügen ungültiger Daten oder durch Blockieren eines Kommunikationspfads Analyse des Quellcodes Für das erfolgreiche Entwickeln der sicherheitskritischen Applikationen einer ECU muss bereits der Compiler entsprechend qualifiziert sein zum Beispiel die Compiler-Toolsets von Tasking Doch selbst für einen qualifizierten Compiler sind – wie für alle genutzten Tools – gemäß ISO26262 die Risiken zu bewerten Auch jeder Compiler hat Fehler Alle bekannten sind im sogenannten Errata-Sheet aufgelistet Bei sicherheitskritischen Applikationen ist der Quellcode zu analysieren und zu prüfen ob er von bekannten Compiler-Bugs betroffen sein könnte Meist geschieht das manuell Es gibt jedoch Tools wie den »TriCore Inspector« von Tasking der Quellcode automatisch auf alle bekannten Compiler-Probleme untersucht und einen entsprechenden Bericht ausgibt Entwickler können den Bericht entweder zum Anpassen des Quellcodes verwenden oder einfach an den Risikobewertungsbericht anhängen Nach dem Compiler ist der Code selbst auf Fehler zu überprüfen unter anderem in Bezug auf die Anforderungen an die FFI Hier helfen Tools wie der »Safety Checker« von Tasking vergleichbar mit einer statischen Code-Analyse die völlig Compilerunabhängig ist Der Entwickler beschreibt dem Tool die beabsichtigten Zugriffsrechte aller Sicherheitsund QM-Partitionen im System also Lese-Schreibund Ausführungsrechte für bestimmte Speicherbereiche Anschließend prüft das Tool den gesamten Quellcode und versucht potenzielle Lecks zu identifizieren Also eventuell mögliche Interferenzen zwischen den Partitionen zum Beispiel durch unsicheres unzureichend abgesichertes Verwenden von Pointern globalen Variablen oder gemeinsam genutzten Speichern Dabei geht man davon aus dass man das Trennen zwischen den Partitionen nicht mit Hardware-Methoden also Hilfsmitteln wie einer Memory Protection Unit MPU oder einem Hypervisor erreicht Entweder sind solche Methoden nicht geplant oder verfügbar oder sie sind noch nicht aktiviert Im letzteren Fall hilft das Tool bei der Fehlersuche oder beim Vorbereiten der Software auf eine MPU Anstatt eine MPU-Ausnahme nach der anderen zu debuggen Bild 1 Verschiedene Applikationen innerhalb einer ECU können unterschiedliche Anforderungen an die funktionale Sicherheit stellen Bild Tasking Bild 2 Hardware-Debuggingund Testaufbau am Beispiel eines Infineon-»Aurix«-basierten Zielsystems Bild Tasking