Autor: Kristian Trenkel, iSyst Intelligente Systeme GmbH<\/p>\n
Die ISO 26262 enth\u00e4lt Vorgaben f\u00fcr die Qualifizierung von Software-Tools, welche f\u00fcr die Entwicklung und den Test sicherheitskritischer Systeme einzusetzen sind. In der Praxis jedoch gehen die Auslegungen der verschiedenen Vorgaben weit auseinander. Dieser Betrag beschreibt die praktischen Erfahrungen mit der Tool-Qualifizierung des Testautomatisierungswerkzeuges iTestStudio bei einem Tier1. Weiterhin wird ein m\u00f6gliches Vorgehen zur Tool-Qualifizierung dargestellt. Am Ende bleibt aber die Frage, wie der Inhalt der Norm zu interpretieren ist.<\/strong><\/p>\n In der Automobilindustrie kommen immer mehr sicherheitskritische Funktionen, wie zum Beispiel Notbremsassistent, Spurhalteassistent und autonomes Fahren, zum Einsatz im Fahrzeug. Zur Entwicklung und zum Test dieser Systeme sind die Vorgaben der ISO 26262 [1] zu beachten. Dabei stellt diese Norm nicht nur Anforderungen an den Entwicklungsprozess und dessen Tools, sondern auch an den Test einschlie\u00dflich der Testmethoden und Testwerkzeuge.<\/p>\n Es gibt f\u00fcr die Test-Tools, wie allgemein f\u00fcr Software-Tools, detaillierte Anforderungen, welche im Rahmen einer Tool-Qualifizierung zu bewerten sind.<\/p>\n Der Fokus der ISO 26262 in Bezug auf die Tool-Qualifizierung wird in Kapitel 11.1 [2] wie folgt beschreiben:<\/p>\n „The first objective of this clause is to provide criteria to determine the required level of confidence in a software tool when applicable.“<\/em><\/p>\n Dazu wird eine Bewertung des Tool nach den Vorgaben der ISO 26262 in Kapitel 11 [2] durchgef\u00fchrt. Dabei wird einerseits der Tool Impact (TI \u2013 TI1 oder TI2) bewertet, welcher das m\u00f6gliche Einbringen oder Verbergen von Fehlern in sicherheitskritischen Teilen beschreibt. Anderseits wird das Tool Error Detection (TD \u2013 TD1, TD2 oder TD3) untersucht, welches eine Aussage \u00fcber die Zuverl\u00e4ssigkeit des Tools ausdr\u00fcckt. Basierend auf dem TI- und dem TD-Wert wird der Tool Confidence Level (TCL \u2013 TCL1, TCL2 oder TCL3) bestimmt. Je nach TCL-Bewertung sind zus\u00e4tzliche Ma\u00dfnahmen bei der Entwicklung und dem Test des Werkzeugs auszuf\u00fchren.<\/p>\n In der Praxis ist das vordergr\u00fcndige Ziel, eine Einstufung mit TCL1 zu erreichen, da dann keine weiteren Ma\u00dfnahmen erforderlich sind. Dabei zeigt die Erfahrung, dass die Einstufung nicht immer objektiv erfolgt. Es steht oft die Aufwands- und damit Kostenminimierung in der Entwicklungsphase im Mittelpunkt. Beispielsweise werden selbst Compiler in der Praxis mit TCL1 eingestuft. Wobei es realistisch nur schwer m\u00f6glich ist, Fehler, die durch einen Compiler generiert werden, prinzipiell auszuschlie\u00dfen.<\/p>\n Das Testautomatisierungswerkzeuges iTestStudio der iSyst Intelligente Systeme GmbH, welches in diesem Beitrag als Beispiel dienen soll, werden zur Erstellung und automatischen Ausf\u00fchrung von Tests unter Verwendung der Testsysteme z.B. Hardware in the Loop (HiL)-Testsysteme eingesetzt. Dabei wird auf die verschiedenen Test-Tools, wie zum Beispiel CANape, CANalyzer und ControlDesk \u00fcber Automatisierungsschnittstellen (z.B. COM) zugegriffen.<\/p>\n Die Software iTestStudio besteht aus verschiedenen Komponenten, wie sie in Abbildung 1 (siehe\u00a0PDF<\/a>) dargestellt sind.<\/p>\n Das Zusammenspiel der einzelnen Komponenten f\u00fcr die Testausf\u00fchrung ist in Abbildung 2 (siehe\u00a0PDF<\/a>) zu sehen.<\/p>\n Die Komponente iTestStudio TA (Abbildung 3,\u00a0PDF<\/a>) stellt die eigentliche Benutzeroberfl\u00e4che dar. Diese umfasst die Organisation der Testf\u00e4lle mit der Zusammenstellung von Testserien und Testsequenzen (Abbildung 4,\u00a0PDF<\/a>), das Ausf\u00fchrungen\/Starten der Testskripte und das Erstellen der Testreports.<\/p>\n Als zweites sind die TestSupport-Bibliotheken zu betrachten. Diese Bibliotheken k\u00fcmmern sich um die Ausf\u00fchrung der Tests mit der zugeh\u00f6rigen Python-Version, welche nicht zwingend die Python-Version der iTestStudio TA GUI sein muss. Weiterhin sind Funktionen zum Speichern der Ergebnisse enthalten.<\/p>\n Als drittes ist das TestToolkit zu untersuchen. Dieses enth\u00e4lt spezielle Testfunktionen, Schnittstellen zu Tools (wie Vector CANape oder dSPACE ControlDesk) sowie Container f\u00fcr Cal- und Hil-Variablen. Das Zusammenwirken des Testautomatisierungswerkzeuges mit dem Testsystem und verschiedenen Test-Werkzeugen macht die Einsch\u00e4tzung f\u00fcr die Tool-Qualifizierung schnell sehr komplex und dabei schwierig sowie kosten- und zeitintensiv.<\/p>\n Im Rahmen des Einsatzes des iTestStudio f\u00fcr den Test eines Fahrwerksteuerger\u00e4tes mit Einstufung in ASIL B und bei einem Tier1 wurde die Qualifizierung nach ISO\u00a026262 notwendig.<\/p>\n Im ersten Schnitt wurden Dokumente zum Einsatz des iTestStudio sowie eine „Selbsteinsch\u00e4tzung“ vom Verantwortlichen f\u00fcr die funktionale Sicherheit des Tier1 angefordert. In Anlehnung an die ISO 26262 (\u00a0[2] Kapitel 11.4.5 und folgende) wurde ein entsprechendes Dokument erstellt und \u00fcbergeben. Dieses Dokument umfasst Angaben zu m\u00f6glichen Fehlern des Testautomatisierungswerkzeuges, welche zu inkorrekten Bewertungen in den Testberichten f\u00fchren konnten. Es dokumentiert weiterhin, welche Ma\u00dfnahmen ergriffen wurden bzw. bei dem Einsatz zu ergreifen sind, damit dieses Fehlverhalten nicht unentdeckt bleibt.<\/p>\n In der darauf folgenden Besprechungen wurde das Dokument (Umfang 12 Seiten) als zu umfangreich abgelehnt. Bei der weiteren Diskussion stellte sich heraus, dass der Tier1 ein Formular (Excel-Sheet) f\u00fcr die Erfassung der notwendigen Informationen f\u00fcr die Durchf\u00fchrung der Tool-Qualifizierung verwendet. Dieses Dokument sowie ein Beispiel wurden zur Verf\u00fcgung gestellt. Bei n\u00e4herer Betrachtung zeigte sich, dass lediglich eine einzige Zeile innerhalb des Dokumentes f\u00fcr die Eingabe von Daten vorgesehen ist. Dementsprechend war es nicht m\u00f6glich, umfangreichere Informationen in diesem Dokument zu generieren. Die sehr oberfl\u00e4chliche Betrachtung wurde aber durch den Tier1 akzeptiert und f\u00fchrte zu einem TCL1 f\u00fcr das Testautomatisierungswerkzeuges iTestStudio.<\/p>\n Zusammenfassend ist festzustellen, dass die Tool-Qualifizierung durch den Tier1 viel oberfl\u00e4chlicher ablief, als es die Vorgaben der ISO 26262 erwarten lie\u00dfen. Allen Beteiligten, die vorrangig im Test t\u00e4tig sind, erschien dieses Vorgehen als nicht sinnvoll. Im weiteren Vorgehen sollte gekl\u00e4rt werden, wie umfangreich eine Tool-Qualifizierung sein muss.<\/p>\n F\u00fcr den Aufbau von weiterem Knowhow f\u00fcr die funktionale Sicherheit nach ISO 26262 nahm der Autor an der Schulung und Pr\u00fcfung zum „Functional Safety Professional“ des T\u00dcV S\u00fcd teil. Im Rahmen der Schulung wurde auch das Thema der Tool-Qualifizierung sowie die Sicht des T\u00dcV S\u00fcd bez\u00fcglich des notwendigen Umfanges besprochen.<\/p>\n Es ergaben sich dabei die folgenden zentralen Ergebnisse:<\/p>\n Als Ergebnis daraus wurde f\u00fcr das iTestSudio ein Dokument erstellt, welches folgende Punkte umfasst:<\/p>\n F\u00fcr die Betrachtung der Ma\u00dfnahme nach ISO 26262 Kapitel 11.4.6 \u2013 11.4.9 [2] wurde angenommen, dass das iTestStudio nach TCL3 eingestuft wurde. Die notwendigen Ma\u00dfnahmen sind weiterhin abh\u00e4ngig vom ASIL-Level des zu testenden Systems. Mit der Annahme des TCL3 konnten nun m\u00f6glich Ma\u00dfnahmen aus den Kapiteln 11.4.7 \u2013 11.4.9 [2] f\u00fcr alle ASIL-Level betrachtet und Zuordnungen zu bereits durchgef\u00fchrten Aktivit\u00e4ten aufgezeigt werden. Die genannten Kapitel stellen dabei eine bereite Auswahl an Ma\u00dfnahmen bereit, mit denen das Vertrauen in das Tool erh\u00f6ht werden kann und somit ein Einsatz f\u00fcr die Entwicklung und den Test eines sicherheitskritischen Systems vertretbar ist.<\/p>\n Beispielhaft sei das Vorgehen am Punkt d) aus Kapitel 11.4.7.2 mit der Angabe „the occurrence of malfunctions and corresponding erroneous outputs of the software tool acquired during previous developments are accumulated in a systematic way“ beschrieben. Ziel dieses Punktes ist es, das Vertrauen durch Nachverfolgbarkeit von Fehlern und ihrer Behebung zu st\u00e4rken. Im Fall des iTestStudios kommen die Tools TRAC und Subversionen zum Einsatz. Dabei wird TRAC f\u00fcr die Erfassung aller aufgetretenen Fehler sowie f\u00fcr die Dokumentation der Behebung verwendet. Die behobenen Fehler, \u00c4nderungen und Neuerung werden zu jeder Version in Release-Note (changelog.txt) dokumentiert.<\/p>\n Im Ergebnis konnten zu den meisten in der ISO 26262 geforderten Ma\u00dfnahmen auch entsprechende durchgef\u00fchrte Aktivit\u00e4ten zugeordnet werden. Einzig der Punkt 11.4.6 1d) „Development in accordance with a safety standard“ konnte nicht vollst\u00e4ndig dargestellt werden. Wobei die Fu\u00dfnote „QNo safety standard is fully applicable to the development of software tools. Instead, a relevant subset of requirements of the safety standard can be selected.“ in der ISO 26262 [2] auf Seite 25 diesen Punkt nicht sehr aussagekr\u00e4ftig macht.<\/p>\n Zusammenfassend ist festzustellen, dass die ISO 26262 eine recht pr\u00e4zise Handlungsanweisung f\u00fcr die Tool-Qualifizierung bietet. Bei einer entsprechend gr\u00fcndlichen Durchf\u00fchrung kann eine nachvollziehbare und belastbare Einstufung eines Tools erstellt werden.<\/p>\n In der Praxis geht die Qualit\u00e4t dieser Betrachtungen aber leider weit auseinander. Hier w\u00e4re ein einheitliches Vorgehen w\u00fcnschenswert, ja oftmals sogar notwendig, um kleineren Zulieferern den Aufwand f\u00fcr die Erstellung neuer Dokumente f\u00fcr jeden Kunden zu ersparen.<\/p>\n F\u00fcr eine Vereinfachung der Tool-Qualifikation beim Kunden ist es geplant, ein Tool Qualification Kit f\u00fcr das iTestStudio zu erstellen. Dies Kit wird besten aus:<\/p>\n Bei der Zusammenstellung der Umf\u00e4nge des Tool Qualification Kits hat sich gezeigt, dass die meisten Teile bereits vorhanden waren. Es lassen sich interne Dokumente sowie die Beschreibung der Umgebung f\u00fcr die internen Tests des Tools mit kleinen Anpassungen einsetzen.<\/p>\n Die Erfahrung zeigt, dass das Thema Tool-Qualifizierung nach ISO\u00a026262 in verschiedenen Unternehmen sehr unterschiedlich betrachten wird. Nur in seltenen F\u00e4llen werden sehr tiefgehende Betrachtungen durchgef\u00fchrt. Meist geht es aber nur darum, einen TCL1 mit m\u00f6glichst minimalem Aufwand zu bewerten, wie dies in diesem Beitrag beschreiben ist.<\/p>\n Aus Sicht eines Testers ist dieses Vorgehen kurzsichtig bzw. sogar fahrl\u00e4ssig. Die Vorgaben der ISO 26262 sind sinnvoll und sollten ber\u00fccksichtigt werden. Einerseits hat sich bei der eigenen Bewertung des Tools iTestStudio gezeigt, dass eine unvoreingenommene Betrachtung dazu f\u00fchrt, eigene Schw\u00e4chen in der Entwicklung zu erkennen und eine Verbesserung der Qualit\u00e4t des eigenen Tools zu erreichen. Andererseits deckt ein typischer Entwicklungsprozess (z.B. nach dem V-Modell) bereits einen Gro\u00dfteil der Anforderungen der ISO 26262 ab.<\/p>\n Wenn von Beginn der Entwicklung an die Prozessvorgaben eingehalten werden, dann ist f\u00fcr die Tool-Qualifizierung nach ISO 26262 kein signifikanter Mehraufwand notwendig.\u00a0 Insgesamt w\u00e4re ein einheitliches Vorgehen der verschiedenen Firmen (vor allem des OEMs und Tier1s) im Bereich der Tool-Qualifizierung w\u00fcnschenswert.<\/p>\nTool-Qualifizierung nach ISO 26262<\/h2>\n
Das Tool iTestStudio<\/h2>\n
iTestStdio TA
\n<\/em><\/h3>\nTestSupport-Bibliotheken<\/h3>\n
TestToolkit<\/h3>\n
Die Qualifizierung beim Tier1<\/h2>\n
Eigenes Vorgehen zur Tool-Qualifizierung<\/h2>\n
\n
\n
Zuk\u00fcnftige Planung<\/h2>\n
\n
Zusammenfassung<\/h2>\n
Quellenverzeichnis<\/h2>\n