Aspekte der ISO 26262 beim Einsatz von SW-Werkzeugen in verteilter Entwicklung

Eclipse Demo Camp | Stuttgart | 23.11.2010

Aspekte der ISO 26262 beim Einsatz von Software-Werkzeugen
Eclipse Demo Camp, Stuttgart, 23.11.2010
Stefan Kriso, Corporate Research and Advance Engineering, Robert Bosch GmbH, Stuttgart
1 CR/AEY1-Kriso | 09.11.2010 | 0304 | © Robert Bosch GmbH 2010. Alle Rechte vorbehalten, auch bzgl. jeder Verfügung, Verwertung,
Reproduktion, Bearbeitung, Weitergabe sowie für den Fall von Schutzrechtsanmeldungen.


ISO 26262 – Was ist das?
 Norm zur „Funktionalen Sicherheit“
von Straßenfahrzeugen

 Betrachtungsgegenstand sind Systeme
mit elektrischen/ elektronischen
Komponenten („E/E systems“)

 im Entstehen, „Draft International
Standard (ISO/DIS)“ seit 08.07.2009
veröffentlicht; Veröffentlichung ISO
26262 voraussichtlich 07/2011

 Produkthaftung: Umsetzung der ISO
26262 notwendig!



Qualifikation von Software-Tools
 Werkzeuge bestehend aus Software, die bei der Entwicklung
sicherheitsrelevanter Fahrzeugfunktionen zum Einsatz kommen

Software Tool ≠ Tool für Software-Entwicklung

 „Confidence in the use of software tools“ ist beschrieben in ISO 26262,
Band 8, Kapitel 11

 Ziel: Ein Fehler eines Software-Tools
darf nicht zur Verletzung eines
Sicherheitsziels führen.



Vorgehensweise
[nach ISO 26262-8, BL17.1] Tool Tool Tool
Impact Error Confidence ASIL
ASIL
Detection Level

Qualification
Qualification
TCL 33
TCL methods for TCL 33
methods for TCL

TD 33
TD

Qualification
Qualification
TI 22
TI TD 22
TD TCL 22
TCL methods for TCL 22
methods for TCL
Tool
Tool
functions
functions TD 11
TD
and their
and their
use cases
use cases No qualification
No qualification
TI 11
TI TCL 11
TCL required
required

Tool Classification Tool Qualification



1. Schritt: Tool Classification
 Classification betrachtet die Einbettung des Software-Werkzeugs in
den Produktentwicklungsprozess
 Use cases, Tool Impact: Was wird mit dem Werkzeug gemacht?

 Tool Error Detection: Wie gut können fehlerhafte Ausgaben des

Werkzeugs vermieden oder gefunden werden (z.B. Tests, Reviews)?

 Folge: Classification kann nur im Kontext des Werkzeugeinsatzes
durchgeführt werden

 Verantwortung liegt beim Anwender des Tools!



2. Schritt: Tool Qualification

[ISO 26262-8, BL17.1, Table 4 & 5]

 Grad der Empfehlung für die anzuwendenden Methoden hängt ab von der
Sicherheitsrelevanz (ASIL) des zu entwickelnden Produkts ( i.A. nur dem
Anwender des Werkzeugs bekannt)
 Auf eine ggf. notwendige Qualification kann verzichtet werden, wenn durch eine
Anpassung des Produktentwicklungsprozesses die Tool Error Detection erhöht
wird ( TD1)



Wie kann ein Tool-Hersteller die Qualifikation unterstützen?
4.
3. Annahme an die
Annahme an die
Annahmen an die Tool
Annahmen an die Tool Sicherheitsrelevanz des
Sicherheitsrelevanz des
Error Detection im
Error Detection im Produkts: ASIL (A), (B), (C), D
Produkts: ASIL (A), (B), (C), D
Produktentwicklungs-
Produktentwicklungs-
prozess: (TD2), TD3
prozess: (TD2), TD3

2.
Annahme eines
Annahme eines
positiven Tool
positiven Tool
Impacts: TI2
Impacts: TI2

5.
Anwenden geeigneter
Anwenden geeigneter
1. Qualifikationsmethoden und
Qualifikationsmethoden und
Betrachtung von
Betrachtung von Nachweis, dass betrachtete Fehler
Nachweis, dass betrachtete Fehler
Standard use cases
Standard use cases der Standard Use cases im Tool
der Standard Use cases im Tool
mit ihren potenziellen
mit ihren potenziellen verhindert werden
verhindert werden
Fehlern
Fehlern



Qualifikationsmaßnahmen beim Tool-Hersteller
Increased confidence from use ( bei ASIL D evtl. nicht ausreichend)
 Nutzung einer möglicherweise relativ großen Datenbasis des Tool-Herstellers

Evaluation of the tool development process ( bei ASIL D evtl. nicht ausreichend)
 Grundvoraussetzung: Umsetzung eines „angemessenen“ Standards + Assessment

 relevante CMMI Process Areas: CM, PMC, PP, PPQA, REQM, SAM; PI, RD, TS,

VAL, VER
Validation of the software tool
 Regressionstests

 Herunterbrechen der use cases in Requirements, Ableiten relevanter Test cases

 Betrachtung von Fehlgebrauch, unvollständige Eingangsdaten, unerlaubten

Konfigurationseinstellungen, …
Development in accordance with a safety standard
 unüblich/aufwändig bei „Massentools“, eher bei „speziellen“ Tools der Fall (in der

Vergangenheit eher in der Avionik als im Automobilbereich)



Bedeutung einer Zertifizierung (1)
Ein Zertifikat muss enthalten: Der Anwender muss leisten:

„Zertifikat“
1. Betrachtete use cases und
1. Abgleich der use cases und
deren potenzielle Fehler
ggf. Qualifikation der nicht
2. Anforderungen an den betrachteten use cases
Produktentwicklungsprozess, 2. Abgleich der Anforderungen an
in dem das Tool zum Einsatz den Entwicklungsprozess und
kommen kann ggf. dessen Anpassung
3. Annahme über den maximalen 3. Berücksichtigung des max. ASIL
ASIL des Produkts 4. evtl. Assessment der beim
4. Information über die durch- Tool-Hersteller durchgeführten
geführten Qualifikations- Maßnahmen
maßnahmen



Bedeutung einer Zertifizierung (2)
 Welchen Benefit bringt ein „Zertifikat“ ggü. einer reinen „Technischen
Dokumentation“??

Zertifizierung ist weder normativ gefordert noch unbedingt sinnvoll

 Letztendliche Verantwortung für den richtigen Einsatz qualifizierter Tools
verbleibt beim Anwender

 Es ist vom Anwender kritisch zu hinterfragen, ob ein Zertifikat das
leistet, was es zu versprechen scheint!



Unternehmensbereich Kraftfahrzeugtechnik
Automotive Electronics Car Multimedia
10 Geschäftsbereiche…
Gasoline Systems

Diesel Systems

Starter Motors
and Generators Chassis Systems Brakes

Electrical Drives
Chassis Systems Control

1) ZF
Steering Systems1) Automotive Aftermarket
Lenksysteme GmbH (50% Bosch)

… an 131 Standorten in 30 Ländern
… mit 168.571 Mitarbeitern

[Stand: 1. Januar 2009]



Verteilte Entwicklung
 … führt zur verteilten Anwendung von Tools
 Standortübergreifend

 Geschäftsbereichsübergreifend

 Kulturkreisübergreifend

 Firmenübergreifend

 Zeitzonenübergreifend

 … und damit zur Steigerung der Komplexität bei der Tool-Qualfikation
 Use cases inkl. ihrer potenziellen zusätzlichen Fehlermöglichkeiten,

die sich durch die verteilte Anwendung des Tools ergeben
 Inhomogenitäten in den Produktentwicklungsprozessen ( kann zu

unterschiedlichen/neuen use cases führen)



Ein paar Zahlen…
Bosch hat frühzeitig mit der Qualifikation der verwendeten Software-Tools begonnen:

 56 Organisationseinheiten
 ca. 1.500 „spezielle“ Tools, z.B. Compiler
 sehr wenig use cases ohne Tool Impact (TI1), jedoch sehr oft eine hohe Tool Error
Detection (TD1) durch nachgelagerte Reviews/Tests/Tools  TCL1
 31 Tools (2%) mit TCL2 oder TCL3  hauptsächlich an den „Rändern“ des V-
Modells

 Aufwand entsteht in erster Linie bei Schritt 1 (Klassifikation)

 Hinzu kommen ca. 150 relevante „Standard“-Tools (z.B. OS, Office, ZIP,
Verschlüsselung, …) mit z.T. bis zu 130.000 Installationen
 Anfrage bei Tool-Herstellern wurde gestartet (Dokumentation von Anforderungen,
Tests, Freigaben, Fehlertracking, Entwicklungsprozess, …?)



Zusammenfassung
 Zur Reduktion unberechenbarer Produkthaftungsrisiken müssen Systeme, die ab
Veröffentlichung der ISO 26262 (07/2011) in Verkehr gebracht werden, normkonform sein.

 Die ISO 26262 fordert die Verwendung vertrauenswürdiger Software-Werkzeuge; diese
sind also frühzeitig zu klassifizieren und ggf. zu qualifizieren, so dass sie im Produkt-
entwicklungsprozess rechtzeitig zur Verfügung stehen.

 Erfahrungsgemäß liegt der größte Aufwand in der Klassifikation, weniger in der
nachgelagerten Qualifikation.

 Die Verantwortung für die Werkzeugqualifikation liegt beim Anwender; Tool-Hersteller
können durch eine Vorabqualifikation von Standard-use cases den Prozess jedoch
unterstützen.

 Eine Zertifizierung ist weder normativ gefordert noch in jedem Fall sinnvoll.

 Verteilte Entwicklung führt möglicherweise zu zusätzlichen use cases und
Fehlermöglichkeiten, die es zu berücksichtigen gilt.


Aspekte der ISO 26262 beim Einsatz von SW-Werkzeugen in verteilter Entwicklung

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (17)

Mehr von Intland Software GmbH

Mehr von Intland Software GmbH (20)

Aspekte der ISO 26262 beim Einsatz von SW-Werkzeugen in verteilter Entwicklung