Eclipse Demo Camp | Stuttgart | 23.11.2010Aspekte der ISO 26262 beim Einsatz von Software-WerkzeugenEclipse Demo Camp, Stu...
Eclipse Demo Camp | Stuttgart | 23.11.2010    ISO 26262 – Was ist das?          Norm zur „Funktionalen Sicherheit“       ...
Eclipse Demo Camp | Stuttgart | 23.11.2010    Qualifikation von Software-Tools          Werkzeuge bestehend aus Software,...
Eclipse Demo Camp | Stuttgart | 23.11.2010    Vorgehensweise    [nach ISO 26262-8, BL17.1]                      Tool      ...
Eclipse Demo Camp | Stuttgart | 23.11.2010    1. Schritt: Tool Classification          Classification betrachtet die Einb...
Eclipse Demo Camp | Stuttgart | 23.11.2010    2. Schritt: Tool Qualification                                              ...
Eclipse Demo Camp | Stuttgart | 23.11.2010        Wie kann ein Tool-Hersteller die Qualifikation unterstützen?            ...
Eclipse Demo Camp | Stuttgart | 23.11.2010    Qualifikationsmaßnahmen beim Tool-Hersteller    Increased confidence from us...
Eclipse Demo Camp | Stuttgart | 23.11.2010    Bedeutung einer Zertifizierung (1)    Ein Zertifikat muss enthalten:        ...
Eclipse Demo Camp | Stuttgart | 23.11.2010     Bedeutung einer Zertifizierung (2)           Welchen Benefit bringt ein „Z...
Eclipse Demo Camp | Stuttgart | 23.11.2010             Unternehmensbereich KraftfahrzeugtechnikAutomotive Electronics     ...
Eclipse Demo Camp | Stuttgart | 23.11.2010     Verteilte Entwicklung           … führt zur verteilten Anwendung von Tools...
Eclipse Demo Camp | Stuttgart | 23.11.2010     Ein paar Zahlen…     Bosch hat frühzeitig mit der Qualifikation der verwend...
Eclipse Demo Camp | Stuttgart | 23.11.2010     Zusammenfassung           Zur Reduktion unberechenbarer Produkthaftungsris...
Nächste SlideShare
Wird geladen in …5
×

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

2.679 Aufrufe

Veröffentlicht am

Veröffentlicht in: Automobil, Technologie
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
2.679
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
5
Aktionen
Geteilt
0
Downloads
61
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

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

  1. 1. Eclipse Demo Camp | Stuttgart | 23.11.2010Aspekte der ISO 26262 beim Einsatz von Software-WerkzeugenEclipse Demo Camp, Stuttgart, 23.11.2010Stefan Kriso, Corporate Research and Advance Engineering, Robert Bosch GmbH, Stuttgart1 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.
  2. 2. Eclipse Demo Camp | Stuttgart | 23.11.2010 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!2 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.
  3. 3. Eclipse Demo Camp | Stuttgart | 23.11.2010 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.3 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.
  4. 4. Eclipse Demo Camp | Stuttgart | 23.11.2010 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 Qualification4 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.
  5. 5. Eclipse Demo Camp | Stuttgart | 23.11.2010 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!5 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.
  6. 6. Eclipse Demo Camp | Stuttgart | 23.11.2010 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)6 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.
  7. 7. Eclipse Demo Camp | Stuttgart | 23.11.2010 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 geeigneter1. 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 Fehlern7 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.
  8. 8. Eclipse Demo Camp | Stuttgart | 23.11.2010 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)8 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.
  9. 9. Eclipse Demo Camp | Stuttgart | 23.11.2010 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ßnahmen9 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.
  10. 10. Eclipse Demo Camp | Stuttgart | 23.11.2010 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!10 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.
  11. 11. Eclipse Demo Camp | Stuttgart | 23.11.2010 Unternehmensbereich KraftfahrzeugtechnikAutomotive Electronics Car Multimedia 10 Geschäftsbereiche… Gasoline Systems Diesel Systems Starter Motorsand Generators Chassis Systems Brakes Electrical DrivesChassis 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]11 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.
  12. 12. Eclipse Demo Camp | Stuttgart | 23.11.2010 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)12 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.
  13. 13. Eclipse Demo Camp | Stuttgart | 23.11.2010 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, …?)13 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.
  14. 14. Eclipse Demo Camp | Stuttgart | 23.11.2010 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.14 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.

×