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.
Autonomes Fahren | STandards 10 2020 Elektronik automotive 41 41 Regeln MISRA C 2012 5 die für den Automotive-Bereich gedacht waren und dort zu Hause sind und auf die an anderer Stelle in ISO 26262 sogar hingewiesen wird in der Notiz zu Tabelle 6 in Abschnitt 8 4 4 in Teil 6 Nach DO-178 im Glossar in Anhang Bist toter Code ausführbarer ObjektCode der nicht ausgeführt werden kann executable object code … which … cannot be executed … Solchen toten Code findet man durch Strukturüberdeckungsanalyse Im Gegensatz zu DO-178 definiert die MISRA-Regel 2 2 There shall be no dead code toten Code als jede Operation die ausgeführt wird deren Entfernung jedoch das Programmverhalten nicht beeinflusst Any operation that is executed but whose removal would not affect program behavior constitutes dead code Hierbei ist nicht das zeitliche Verhalten des Programms gemeint und auch nicht der Speicherbedarf beides kann sehr wohl durch toten Code im Sinne von MISRA verändert werden Vorsicht Code der eine Ausnahmebehandlung bewirken kann zum Beispiel eine Division durch 0 kann laut MISRA kein toter Code sein denn die Ausnahmebehandlung kann nach außen sichtbar werden Bei DO-178 kann also toter Code nicht ausgeführt werden bei MISRA muss er es aber Die MISRA-Regel 2 2 sagt auch explizit dass Code der nicht erreicht und somit nicht ausgeführt werden kann kein toter Code ist unreachable code is not dead code as it cannot be executed Leider bietet die ISO 26262 keine Definition von totem Code um diesen Widerspruch aufzuklären In Abschnitt 9 4 4 in dem es um Strukturüberdeckung auf Software-Unit-Ebene geht wird in Beispiel 2 als Beispiel für toten Code Code fürs Debugging genannt … accepted dead code e g code for debugging … Code fürs Debugging wäre aber eher in der Kategorie deactivated zu sehen Laut MISRA kann also toter Code sehr wohl ausgeführt werden und würde somit durch die Messung der Strukturüberdeckung nicht aufgedeckt Im Fall der Verifikation der Softwareintegration könnte das beispielsweise eine Unit sein die zwar von einer anderen Unit aufgerufen wird deren Aufruf aber das Programmverhalten nach außen nicht ändert In Bild 4 wird zumindest beim Einsatz des GNU-C-Compilers gcc ohne Optimierung die Funktion increment aus der Funktion use_increment heraus aufgerufen Wenn also ein Testfall use_increment aufruft ergibt sich eine Funktionenüberdeckung von 100 Prozent Aber der Aufruf von increment bewirkt nach außen nichts weil die Variable a nur im Gültigkeitsbereich von increment geändert wird diese Änderung wird in use_increment nicht sichtbar Oder anders ausgedrückt In use_increment hat die Variable a immer den Wert 1 sowohl vor dem Aufruf von increment als auch danach Also liegt toter Code laut MISRA vor der aber durch die Funktionenüberdeckung nicht enthüllt wird Wird der Code in Bild 4 mit Optimierung übersetzt bei gcc zum Beispiel mit -O3 so wird der Aufruf der Funktion increment und die ganze Funktion increment wegoptimiert Schlussfolgerung Bei der Strukturüberdeckung auf der Architekturebene ergeben sich einige Merkwürdigkeiten und Ungereimtheiten Es ist daher wichtig die Hintergründe zu kennen um die Forderungen des Standards ISO 26262 richtig einschätzen zu können ECK Literatur + Links 1 ISO 26262 International Standard Road vehicles Functional Safety Second edition 2018 2 DIN EN 61508 VDE 0803 2011-02 DIN Deutsches Institut für Normung e Vund VDE Verband der Elektrotechnik Elektronik Informationstechnik e V IEC 61508 2010 3 www hitex de tessy 4 Software Considerations In Airborne Systems And Equipment Certification RTCA 1992 5 MISRA-C 2012 Guidelines for the use of the Clanguage in critical systems 2013 MIRA Limited Nuneaton UK Bild 3 Strukturüberdeckungsmaße auf der Software-Unit-Ebene Tabelle 9 Bild 4 Beispiel für toten Code laut MISRA der durch die Strukturüberdeckungsanalyse nicht aufgedeckt wird Frank Büchner hat ein Diplom in Informatik von der Technischen Hochschule Karlsruhe Seit mehreren Jahren widmet er sich dem Thema Testen und SoftwareQualität Seine Kenntnisse vermittelt er regelmäßig durch Vorträge und Fachartikel Momentan arbeitet er als Principal Engineer Software Quality bei Hitex in Karlsruhe frank buechner@hitex de DOPPLER SIMULATOR MDS 77 Tel 0 29 42 9 79 26 -0 59590 Geseke Germany info@heicks de · www heicks de Für die Überprüfung und Justage von modernen Fahrzeug-Radar-Systemen im 77 GHz Bereich Heicks_EKauto_10_20 pdf S 1 Format 42 00 x 128 00 mm 22 Sep 2020 10 09 55