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

1

Eclipse Demo Camp | Stuttgart | 23.11.2010

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.

Aspekte der ISO 26262 beim Einsatz von SoftwareAspekte der ISO 26262 beim Einsatz von Software--WerkzeugenWerkzeugenEclipse Demo Camp, Stuttgart, 23.11.2010Eclipse Demo Camp, Stuttgart, 23.11.2010Stefan Kriso, Corporate Research and Advance Engineering, RobertStefan Kriso, Corporate Research and Advance Engineering, Robert Bosch GmbH, StuttgartBosch GmbH, Stuttgart

2



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 InternationalStandard (ISO/DIS)“ seit 08.07.2009 veröffentlicht; Veröffentlichung ISO 26262 voraussichtlich 07/2011

Produkthaftung: Umsetzung der ISO 26262 notwendig!

3



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-Toolsdarf nicht zur Verletzung einesSicherheitsziels führen.

4



Vorgehensweise

Tool functions and their

use cases

Tool Tool functions functions and their and their

use casesuse cases

TI 2TI 2TI 2

TI 1TI 1TI 1

TD 3TD 3TD 3

TD 2TD 2TD 2

TD 1TD 1TD 1

TCL 3TCL 3TCL 3

TCL 2TCL 2TCL 2

TCL 1TCL 1TCL 1

Tool Tool ImpactImpact

Tool Tool Error Error

DetectionDetection

Tool Tool Confidence Confidence

LevelLevel

Qualification methods for TCL 3

Qualification Qualification methods for TCL 3methods for TCL 3

Qualification methods for TCL 2

Qualification Qualification methods for TCL 2methods for TCL 2

No qualification required

No qualification No qualification requiredrequired

ASILASILASIL

Tool ClassificationTool Classification Tool QualificationTool Qualification

[nach ISO 26262-8, BL17.1]

5



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 Werkzeugeinsatzesdurchgeführt werden

Verantwortung liegt beim Anwender des Tools!

6



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)

7



Wie kann ein Tool-Hersteller die Qualifikation unterstützen?

Betrachtung von Standard use cases mit ihren potenziellen Fehlern

Betrachtung von Standard use cases mit ihren potenziellen Fehlern

Annahme eines positiven Tool Impacts: TI2

Annahme eines positiven Tool Impacts: TI2

Annahmen an die Tool Error Detection im Produktentwicklungs-prozess: (TD2), TD3

Annahmen an die Tool Error Detection im Produktentwicklungs-prozess: (TD2), TD3

Annahme an die Sicherheitsrelevanz des Produkts: ASIL (A), (B), (C), D

Annahme an die Sicherheitsrelevanz des Produkts: ASIL (A), (B), (C), D

Anwenden geeigneter Qualifikationsmethoden und Nachweis, dass betrachtete Fehler der Standard Use cases im Tool verhindert werden

Anwenden geeigneter Qualifikationsmethoden und Nachweis, dass betrachtete Fehler der Standard Use cases im Tool verhindert werden

1.

2.

3.4.

5.

8



Qualifikationsmaßnahmen beim Tool-HerstellerIncreased 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)

9



Bedeutung einer Zertifizierung (1)Ein Zertifikat muss enthalten:

„Zertifikat“1. Betrachtete use cases und

deren potenzielle Fehler2. Anforderungen an den

Produktentwicklungsprozess, in dem das Tool zum Einsatz kommen kann

3. Annahme über den maximalen ASIL des Produkts

4. Information über die durch-geführten Qualifikations-maßnahmen

Der Anwender muss leisten:

1. Abgleich der use cases und ggf. Qualifikation der nicht betrachteten use cases

2. Abgleich der Anforderungen an den Entwicklungsprozess und ggf. dessen Anpassung

3. Berücksichtigung des max. ASIL4. evtl. Assessment der beim

Tool-Hersteller durchgeführten Maßnahmen

10



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

Dokumentation“??

Zertifizierung ist weder normativ gefordert noch unbedingt sinnvZertifizierung ist weder normativ gefordert noch unbedingt sinnvolloll

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!

1111



Unternehmensbereich Kraftfahrzeugtechnik

Steering Systems1) Automotive Aftermarket

Automotive ElectronicsAutomotive Electronics Car MultimediaCar Multimedia

Starter Motorsand Generators

Electrical DrivesElectrical Drives

Gasoline SystemsGasoline Systems

Chassis Systems Control

Chassis Systems Brakes

Diesel SystemsDiesel Systems

1) ZF Lenksysteme GmbH (50% Bosch)

Starter Motorsand Generators

10 Geschäftsbereiche…

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

[Stand: 1. Januar 2009]

12



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)

13



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, …?)

14



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

Automotive

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