• Twitter
  • LinkedIn
  • Xing
+49 7353 981781
Heicon Ulm
  • HOME
  • UNTERNEHMEN
  • PRODUKTE
  • HEICON BLOG
  • Deutsch
    • Deutsch
    • English
  • Menü Menü
Du bist hier: Startseite1 / FuSi_Allgemein2 / Strukturelle Source Code Überdeckung auf dem Target!

Strukturelle Source Code Überdeckung auf dem Target!

FuSi_Allgemein

Die 100%ige strukturelle Source Code Überdeckung wird ja inzwischen von fast allen Normen (IEC61508, ISO26262, DO 178C etc.) der Funktionalen Sicherheit eindeutig gefordert. Unterschieden wird in den einzelnen SIL/ASIL Leveln nur noch die Art der Source Code Coverage.

Strukturelle Source Code Überdeckung:

Im Wesentlichen werden die Statement Coverage (niedrige SIL/ASIL Level), die Branch Coverage und die MC/DC Coverage (hohe SIL/ASIL Level) gefordert. Aus guten Gründen wird aber z.B. keine Pfad Coverage gefordert. Diese würden bedeuten, dass man alle Kombinationen von Pfaden die in einer Software möglich sind überprüfen würde. Das wäre ein extrem hohes Vielfaches von Testfällen im Vergleich zu einer MC/DC Coverage.
Im nachfolgenden Blog möchte ich nun die Frage thematisieren, welche Vor- bzw. Nachteile sich ergeben, wenn man die Coverage auf der finalen Hardware ermittelt im Gegensatz zu einer Coverage Ermittlung auf einem vom Compilerhersteller zur Verfügung gestellten Simulator der auf dem PC ausgeführt wird.
Spontan wird man sicher zu der Meinung kommen, dass eine Coverage Messung auf der finalen Hardware die aus Sicherheitsgründen beste Methode ist. Einige immer wieder vorgetragene Argumente sind: Toter Code würde unter realen Bedingungen gefunden. Die Coverage würde nachgwiesen unter Berücksichtigung der realen HW/SW Schnittstellen. Mancher bisheriger, formaler Unittest könnte gespart werden.
Für eine aussagekräftige Antwort, muss noch geklärt werden ob mit Hardware „nur“ der Mikrocontroller und dessen Periferie gemeint ist, oder ob die gesamte Hardware inklusive I/Os, FPGAs etc. verwendet wird.

Die Messung von Code Coverage unter Aussführung des Source Codes auf dem Mikrocontrollers ist in der Luftfahrt seit Jahrzehnten schon gängige Praxis. Aus dieser langjährigen Erfahrung geht eindeutig hervor, dass es so gut wie keine Fehler gibt, die man hier zusätzlich findet. Ein Test auf einem Simulator zeigt in den allermeisten Fällen genau die gleichen Fehler auf. Hier gibt es keinen erkennbaren Vorteil des Tests auf dem Target. Es sei hier noch angemerkt, dass bei diesem Verfahren praktisch nie die gesamte Software auf einmal instrumentiert wird, sondern immer nur relativ kleine Teile. Aufgrund entsprechend vorhandener Tools auf dem Markt ist es aber kein großer Aufwand am Ende die vollständige Coverage zu ermitteln.
Unter einem „echten“ Test auf der Hardware versteht man aber meist die vollständige Hardware (inklusive I/Os, FPGAs etc.). Mit den bisher üblichen Methoden der Coverage Messung ergibt sich nun aber das Problem, dass sich das Timing Verhalten der Software sowie der Speicherbedarf massiv verändern, wenn die Software instrumentiert ist. Die Instrumentierung ist wiederum notwendig um die Coverage überhaupt ermitteln zu können. Dies bedeutet, in der Praxis ganz oft, dass die Software gar nicht mehr oder nur sehr eingeschränkt lauffähig ist auf der echten Hardware. Um trotzdem Tests auf diese Art und Weise durchzuführen wird nun oft versucht auch hier nur Teile der Software zu instrumentieren, Tests entsprechend durchzuführen und die Gesamt Coverage dann auf zu addieren. Das Problem ist aber hier, dass dafür keine kommerzielle Toolunterstützung zur Verfügung steht. Damit ensteht ein in der Praxis völlig inakzepabler Aufwand zur Ermittlung der Gesamt Coverage. Bei sehr zeitkritischen Systemen kann jegliche Instrumentierung dazu führen, dass ein sinnvoller Test gar nicht mehr möglich ist.

Lösungsansätze:

Die offensichtliche Lösung des obigen Problems ist eine Technologie die es nicht mehr erfordert den Source Code zu verändern, die aber trotzdem die Code Coverage messen kann. Aktuell gibt es einige vielversprechende Entwicklungen von einigen Toolherstellern in diese Richtung. Für ausgewählte Hardware Architekturen sind einige Lösungen auch schon nahe an der Marktreife.
In der Luftfahrtbranche hat sich über die Jahre auch noch eine Vorgehensweise herausgebildet, welche die angestrebten Sicherheitsziele durch die Ermittlung der Source Code Coverage auch auf hervorragende Art und Weise erreicht:

  1. Alle Tests (Unit-, Integrations- und Systemtests) werden mit den Compilereinstellungen übersetzt wie Sie auch im operationellen Code verwendet werden.
  2. Die Tests werden zu 100% gegen Requirements erstellt. Die strukturelle Coverage wird nur im Hintergrund ermittelt und immer wenn eine Lücke auftritt wird analysiert wo die Lücke liegt. Es gibt prinzipiell nur 3 mögliche Lücken: unvollständige Requirements, unvollständige Testspezifikationen, nicht benötigter Source Code. Mit diesem Vorgehen wird am Ende ein 100% Source Code Coverage erreicht, die zur 100% durch Requirements basierte Tests abgedeckt ist.

Sind Sie bereit für einen FuSi Workshop um das Verbesserungspotential zu identifizieren? Dann senden Sie eine Mail an info[at]heicon-ulm.de oder vereinbaren Sie einen Telefontermin unter +49 (0) 7353 981 781.

15. Juni 2017/0 Kommentare/von HEICON Global Engineering GmbH
Schlagworte: CENELEC, EN50128, EN50657, Funktionale Sicherheit, IEC61508, ISO26262, RTCA DO178, Software Testing, strukturelle Source Code Überdeckung, Validation, Verifikation
Eintrag teilen
  • Teilen auf Facebook
  • Teilen auf Twitter
  • Teilen auf WhatsApp
  • Teilen auf Pinterest
  • Teilen auf Reddit
https://heicon-ulm.de/wp-content/uploads/2015/01/DI1A6023_klein_Funktionale-Sicherheit.jpg 433 547 HEICON Global Engineering GmbH https://heicon-ulm.de/wp-content/uploads/2020/07/heicon-logo-5.png HEICON Global Engineering GmbH2017-06-15 14:19:412021-02-03 21:39:05Strukturelle Source Code Überdeckung auf dem Target!
Das könnte Dich auch interessieren
Funktionale Sicherheit Funktionale Sicherheit und agile Entwicklungsmethoden – Ein unüberbrückbarer Gegensatz (Teil 2)?
Fault Injection Test in ISO 26262 – Braucht man den wirklich?
ISO26262 ISO 21448 – SOTIF! Wo ist der Mehrwert?
Industrie Funktionale Sicherheitsgrundnorm IEC 61508
Requirement Engineering Wieviele Requirements Ebenen sind sinnvoll?
Funktionale Sicherheit Rückwirkungsfreiheit – Die gelebte Praxis!
0 Kommentare

Hinterlasse einen Kommentar

An der Diskussion beteiligen?
Hinterlasse uns deinen Kommentar!

Schreibe einen Kommentar Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Kategorien

  • A_Requirement Engineering
  • B_Validation und Verifikation
  • C_Konfig-/ Änderungsmanagement
  • D_Security
  • FuSi_Allgemein
  • FuSi_Automotive
  • FuSi_Bahn
  • FuSi_Industrie
  • FuSi_Landwirtschaft
  • FuSi_Luftfahrt

Kontakt

HEICON Global Engineering GmbH
Dipl. Ing. (FH) Martin Heininger
Kreuzweg 22
88477 Schwendi

Tel.: +49 7353 – 98 17 81
Mobil: +49 176 – 24 73 99 60

Email: info[at]heicon-ulm.de

IMPRESSUM  |  DATENSCHUTZ

Guter Safety Software Entwicklungsprozess – Was ist das? Funktionale Sicherheit ISO 26262: Rückwirkungsfreiheit – Was ist das?
Nach oben scrollen