SlideShare ist ein Scribd-Unternehmen logo
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.
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.
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.
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 Qualification


4   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.
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.
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.
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 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



7       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.
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.
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ßnahmen


9   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.
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.
Eclipse Demo Camp | Stuttgart | 23.11.2010

             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]


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.
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.
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.
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.

Weitere ähnliche Inhalte

Andere mochten auch

Instruction Manual E-Trac Metal Detector French Language website 4901 0068-2
Instruction Manual E-Trac Metal Detector French Language  website 4901 0068-2Instruction Manual E-Trac Metal Detector French Language  website 4901 0068-2
Instruction Manual E-Trac Metal Detector French Language website 4901 0068-2
Serious Detecting
 
Ids ips detection
Ids  ips detectionIds  ips detection
Ids ips detection
Tensor
 
Séminaire invité - LIRMM - 23 janvier 2015
Séminaire invité - LIRMM - 23 janvier 2015Séminaire invité - LIRMM - 23 janvier 2015
Séminaire invité - LIRMM - 23 janvier 2015
Adrien Guille
 
2 aaz fonctionnement d'un nids
2 aaz   fonctionnement d'un nids2 aaz   fonctionnement d'un nids
2 aaz fonctionnement d'un nids
kaser info2aaz
 
La détection des spam
La détection des spamLa détection des spam
La détection des spam
Nour El Houda Megherbi
 
Nouvelles approches analytiques pour la détection des fraudes
Nouvelles approches analytiques pour la détection des fraudesNouvelles approches analytiques pour la détection des fraudes
Nouvelles approches analytiques pour la détection des fraudes
Pôle Qualiméditerranée
 
Quick Start Guide Minelab GPX-4000 Metal Detector French Language 4901 0060 ...
Quick Start Guide Minelab GPX-4000 Metal Detector  French Language 4901 0060 ...Quick Start Guide Minelab GPX-4000 Metal Detector  French Language 4901 0060 ...
Quick Start Guide Minelab GPX-4000 Metal Detector French Language 4901 0060 ...
Serious Detecting
 
Hipertensión arterial sistémica
Hipertensión arterial sistémicaHipertensión arterial sistémica
Hipertensión arterial sistémica
Laura Dominguez
 
Instruction Manual Minelab GPX 4800-5000 Metal Detector French Language ...
Instruction Manual Minelab GPX 4800-5000 Metal Detector French Language      ...Instruction Manual Minelab GPX 4800-5000 Metal Detector French Language      ...
Instruction Manual Minelab GPX 4800-5000 Metal Detector French Language ...
Serious Detecting
 
Reconnaissance faciale
Reconnaissance facialeReconnaissance faciale
Reconnaissance faciale
Aymen Fodda
 
SENSIVIC : La détection automatique d'anormalités sonores
SENSIVIC : La détection automatique d'anormalités sonoresSENSIVIC : La détection automatique d'anormalités sonores
SENSIVIC : La détection automatique d'anormalités sonores
Pascale Demartini
 

Andere mochten auch (17)

Instruction Manual E-Trac Metal Detector French Language website 4901 0068-2
Instruction Manual E-Trac Metal Detector French Language  website 4901 0068-2Instruction Manual E-Trac Metal Detector French Language  website 4901 0068-2
Instruction Manual E-Trac Metal Detector French Language website 4901 0068-2
 
Ids ips detection
Ids  ips detectionIds  ips detection
Ids ips detection
 
Introduction à la Conception et Evaluation des IHM
Introduction à la Conception et Evaluation des IHMIntroduction à la Conception et Evaluation des IHM
Introduction à la Conception et Evaluation des IHM
 
LMO08a.ppt
LMO08a.pptLMO08a.ppt
LMO08a.ppt
 
Séminaire invité - LIRMM - 23 janvier 2015
Séminaire invité - LIRMM - 23 janvier 2015Séminaire invité - LIRMM - 23 janvier 2015
Séminaire invité - LIRMM - 23 janvier 2015
 
Les sondes de température
Les sondes de températureLes sondes de température
Les sondes de température
 
2 aaz fonctionnement d'un nids
2 aaz   fonctionnement d'un nids2 aaz   fonctionnement d'un nids
2 aaz fonctionnement d'un nids
 
La détection des spam
La détection des spamLa détection des spam
La détection des spam
 
Détection
Détection Détection
Détection
 
Nouvelles approches analytiques pour la détection des fraudes
Nouvelles approches analytiques pour la détection des fraudesNouvelles approches analytiques pour la détection des fraudes
Nouvelles approches analytiques pour la détection des fraudes
 
Quick Start Guide Minelab GPX-4000 Metal Detector French Language 4901 0060 ...
Quick Start Guide Minelab GPX-4000 Metal Detector  French Language 4901 0060 ...Quick Start Guide Minelab GPX-4000 Metal Detector  French Language 4901 0060 ...
Quick Start Guide Minelab GPX-4000 Metal Detector French Language 4901 0060 ...
 
Hipertensión arterial sistémica
Hipertensión arterial sistémicaHipertensión arterial sistémica
Hipertensión arterial sistémica
 
Les detecteurs tout ou rien
Les detecteurs tout ou rienLes detecteurs tout ou rien
Les detecteurs tout ou rien
 
Instruction Manual Minelab GPX 4800-5000 Metal Detector French Language ...
Instruction Manual Minelab GPX 4800-5000 Metal Detector French Language      ...Instruction Manual Minelab GPX 4800-5000 Metal Detector French Language      ...
Instruction Manual Minelab GPX 4800-5000 Metal Detector French Language ...
 
Reconnaissance faciale
Reconnaissance facialeReconnaissance faciale
Reconnaissance faciale
 
SENSIVIC : La détection automatique d'anormalités sonores
SENSIVIC : La détection automatique d'anormalités sonoresSENSIVIC : La détection automatique d'anormalités sonores
SENSIVIC : La détection automatique d'anormalités sonores
 
Formation traitement d_images
Formation traitement d_imagesFormation traitement d_images
Formation traitement d_images
 

Mehr von Intland Software GmbH

Agile in MedTech: Essential Best Practices, and How to Support Them
Agile in MedTech: Essential Best Practices, and How to Support ThemAgile in MedTech: Essential Best Practices, and How to Support Them
Agile in MedTech: Essential Best Practices, and How to Support Them
Intland Software GmbH
 
Dr. Andreas Birk: Patterns of Agile Success in Medical Device Development
Dr. Andreas Birk: Patterns of Agile Success in Medical Device DevelopmentDr. Andreas Birk: Patterns of Agile Success in Medical Device Development
Dr. Andreas Birk: Patterns of Agile Success in Medical Device Development
Intland Software GmbH
 
Dr. Andreas Birk: Agile Practices for Medical Device Development
Dr. Andreas Birk: Agile Practices for Medical Device DevelopmentDr. Andreas Birk: Agile Practices for Medical Device Development
Dr. Andreas Birk: Agile Practices for Medical Device Development
Intland Software GmbH
 
ISO/PAS 21448 (SOTIF) in the Development of ADAS and Autonomous Vehicles
ISO/PAS 21448 (SOTIF) in the Development of ADAS and Autonomous VehiclesISO/PAS 21448 (SOTIF) in the Development of ADAS and Autonomous Vehicles
ISO/PAS 21448 (SOTIF) in the Development of ADAS and Autonomous Vehicles
Intland Software GmbH
 
Dr. Andreas Birk: Approaches to Agile in Medical Device Development
Dr. Andreas Birk: Approaches to Agile in Medical Device DevelopmentDr. Andreas Birk: Approaches to Agile in Medical Device Development
Dr. Andreas Birk: Approaches to Agile in Medical Device Development
Intland Software GmbH
 
Intland Software | Welcome and Opening Remarks - Intland Connect - 22 Oct 2020
Intland Software | Welcome and Opening Remarks - Intland Connect - 22 Oct 2020Intland Software | Welcome and Opening Remarks - Intland Connect - 22 Oct 2020
Intland Software | Welcome and Opening Remarks - Intland Connect - 22 Oct 2020
Intland Software GmbH
 
Intland Software | Welcome and Opening Remarks - Intland Connect - 21 Oct 2020
Intland Software | Welcome and Opening Remarks - Intland Connect - 21 Oct 2020Intland Software | Welcome and Opening Remarks - Intland Connect - 21 Oct 2020
Intland Software | Welcome and Opening Remarks - Intland Connect - 21 Oct 2020
Intland Software GmbH
 
Intland Software | codeBeamer ALM: What’s in the Pipeline for the Automotive ...
Intland Software | codeBeamer ALM: What’s in the Pipeline for the Automotive ...Intland Software | codeBeamer ALM: What’s in the Pipeline for the Automotive ...
Intland Software | codeBeamer ALM: What’s in the Pipeline for the Automotive ...
Intland Software GmbH
 
Intland Software | Enabling Safe Medical Software Development through a Purpo...
Intland Software | Enabling Safe Medical Software Development through a Purpo...Intland Software | Enabling Safe Medical Software Development through a Purpo...
Intland Software | Enabling Safe Medical Software Development through a Purpo...
Intland Software GmbH
 
Intland Software | Intland Retina: What’s in the Pipeline for the Life Scienc...
Intland Software | Intland Retina: What’s in the Pipeline for the Life Scienc...Intland Software | Intland Retina: What’s in the Pipeline for the Life Scienc...
Intland Software | Intland Retina: What’s in the Pipeline for the Life Scienc...
Intland Software GmbH
 
Volkswagen | ECU Software Development with codeBeamer ALM: IT Aspects
Volkswagen | ECU Software Development with codeBeamer ALM: IT AspectsVolkswagen | ECU Software Development with codeBeamer ALM: IT Aspects
Volkswagen | ECU Software Development with codeBeamer ALM: IT Aspects
Intland Software GmbH
 
FutureLink | Strategic Tooling Decisions in ALM Engineering: Migrate or Coexi...
FutureLink | Strategic Tooling Decisions in ALM Engineering: Migrate or Coexi...FutureLink | Strategic Tooling Decisions in ALM Engineering: Migrate or Coexi...
FutureLink | Strategic Tooling Decisions in ALM Engineering: Migrate or Coexi...
Intland Software GmbH
 
Bertrandt | Automotive Best Practice: How to Design, Review, Approve, and Eff...
Bertrandt | Automotive Best Practice: How to Design, Review, Approve, and Eff...Bertrandt | Automotive Best Practice: How to Design, Review, Approve, and Eff...
Bertrandt | Automotive Best Practice: How to Design, Review, Approve, and Eff...
Intland Software GmbH
 
McKinsey | When Things Get Complex: Complex Systems, Challenges and Where to ...
McKinsey | When Things Get Complex: Complex Systems, Challenges and Where to ...McKinsey | When Things Get Complex: Complex Systems, Challenges and Where to ...
McKinsey | When Things Get Complex: Complex Systems, Challenges and Where to ...
Intland Software GmbH
 
Roche | The Design History File in codeBeamer ALM: Electronic Records, Signat...
Roche | The Design History File in codeBeamer ALM: Electronic Records, Signat...Roche | The Design History File in codeBeamer ALM: Electronic Records, Signat...
Roche | The Design History File in codeBeamer ALM: Electronic Records, Signat...
Intland Software GmbH
 
Cosylab | codeBeamer ALM as a Swiss Army Knife on a Particle Therapy Project
Cosylab | codeBeamer ALM as a Swiss Army Knife on a Particle Therapy ProjectCosylab | codeBeamer ALM as a Swiss Army Knife on a Particle Therapy Project
Cosylab | codeBeamer ALM as a Swiss Army Knife on a Particle Therapy Project
Intland Software GmbH
 
Adesso | Principles of Tool Validation and Infrastructure Qualification using...
Adesso | Principles of Tool Validation and Infrastructure Qualification using...Adesso | Principles of Tool Validation and Infrastructure Qualification using...
Adesso | Principles of Tool Validation and Infrastructure Qualification using...
Intland Software GmbH
 
Automotive SPICE Level 3 and Beyond with codeBeamer ALM
Automotive SPICE Level 3 and Beyond with codeBeamer ALMAutomotive SPICE Level 3 and Beyond with codeBeamer ALM
Automotive SPICE Level 3 and Beyond with codeBeamer ALM
Intland Software GmbH
 
27 Nov 2019 – Experts Talk: Integrated MedTech Delivery from Requirements thr...
27 Nov 2019 – Experts Talk: Integrated MedTech Delivery from Requirements thr...27 Nov 2019 – Experts Talk: Integrated MedTech Delivery from Requirements thr...
27 Nov 2019 – Experts Talk: Integrated MedTech Delivery from Requirements thr...
Intland Software GmbH
 
13 Nov 2019 - Experts Talk: Balancing Innovation, Risks, and Compliance in Me...
13 Nov 2019 - Experts Talk: Balancing Innovation, Risks, and Compliance in Me...13 Nov 2019 - Experts Talk: Balancing Innovation, Risks, and Compliance in Me...
13 Nov 2019 - Experts Talk: Balancing Innovation, Risks, and Compliance in Me...
Intland Software GmbH
 

Mehr von Intland Software GmbH (20)

Agile in MedTech: Essential Best Practices, and How to Support Them
Agile in MedTech: Essential Best Practices, and How to Support ThemAgile in MedTech: Essential Best Practices, and How to Support Them
Agile in MedTech: Essential Best Practices, and How to Support Them
 
Dr. Andreas Birk: Patterns of Agile Success in Medical Device Development
Dr. Andreas Birk: Patterns of Agile Success in Medical Device DevelopmentDr. Andreas Birk: Patterns of Agile Success in Medical Device Development
Dr. Andreas Birk: Patterns of Agile Success in Medical Device Development
 
Dr. Andreas Birk: Agile Practices for Medical Device Development
Dr. Andreas Birk: Agile Practices for Medical Device DevelopmentDr. Andreas Birk: Agile Practices for Medical Device Development
Dr. Andreas Birk: Agile Practices for Medical Device Development
 
ISO/PAS 21448 (SOTIF) in the Development of ADAS and Autonomous Vehicles
ISO/PAS 21448 (SOTIF) in the Development of ADAS and Autonomous VehiclesISO/PAS 21448 (SOTIF) in the Development of ADAS and Autonomous Vehicles
ISO/PAS 21448 (SOTIF) in the Development of ADAS and Autonomous Vehicles
 
Dr. Andreas Birk: Approaches to Agile in Medical Device Development
Dr. Andreas Birk: Approaches to Agile in Medical Device DevelopmentDr. Andreas Birk: Approaches to Agile in Medical Device Development
Dr. Andreas Birk: Approaches to Agile in Medical Device Development
 
Intland Software | Welcome and Opening Remarks - Intland Connect - 22 Oct 2020
Intland Software | Welcome and Opening Remarks - Intland Connect - 22 Oct 2020Intland Software | Welcome and Opening Remarks - Intland Connect - 22 Oct 2020
Intland Software | Welcome and Opening Remarks - Intland Connect - 22 Oct 2020
 
Intland Software | Welcome and Opening Remarks - Intland Connect - 21 Oct 2020
Intland Software | Welcome and Opening Remarks - Intland Connect - 21 Oct 2020Intland Software | Welcome and Opening Remarks - Intland Connect - 21 Oct 2020
Intland Software | Welcome and Opening Remarks - Intland Connect - 21 Oct 2020
 
Intland Software | codeBeamer ALM: What’s in the Pipeline for the Automotive ...
Intland Software | codeBeamer ALM: What’s in the Pipeline for the Automotive ...Intland Software | codeBeamer ALM: What’s in the Pipeline for the Automotive ...
Intland Software | codeBeamer ALM: What’s in the Pipeline for the Automotive ...
 
Intland Software | Enabling Safe Medical Software Development through a Purpo...
Intland Software | Enabling Safe Medical Software Development through a Purpo...Intland Software | Enabling Safe Medical Software Development through a Purpo...
Intland Software | Enabling Safe Medical Software Development through a Purpo...
 
Intland Software | Intland Retina: What’s in the Pipeline for the Life Scienc...
Intland Software | Intland Retina: What’s in the Pipeline for the Life Scienc...Intland Software | Intland Retina: What’s in the Pipeline for the Life Scienc...
Intland Software | Intland Retina: What’s in the Pipeline for the Life Scienc...
 
Volkswagen | ECU Software Development with codeBeamer ALM: IT Aspects
Volkswagen | ECU Software Development with codeBeamer ALM: IT AspectsVolkswagen | ECU Software Development with codeBeamer ALM: IT Aspects
Volkswagen | ECU Software Development with codeBeamer ALM: IT Aspects
 
FutureLink | Strategic Tooling Decisions in ALM Engineering: Migrate or Coexi...
FutureLink | Strategic Tooling Decisions in ALM Engineering: Migrate or Coexi...FutureLink | Strategic Tooling Decisions in ALM Engineering: Migrate or Coexi...
FutureLink | Strategic Tooling Decisions in ALM Engineering: Migrate or Coexi...
 
Bertrandt | Automotive Best Practice: How to Design, Review, Approve, and Eff...
Bertrandt | Automotive Best Practice: How to Design, Review, Approve, and Eff...Bertrandt | Automotive Best Practice: How to Design, Review, Approve, and Eff...
Bertrandt | Automotive Best Practice: How to Design, Review, Approve, and Eff...
 
McKinsey | When Things Get Complex: Complex Systems, Challenges and Where to ...
McKinsey | When Things Get Complex: Complex Systems, Challenges and Where to ...McKinsey | When Things Get Complex: Complex Systems, Challenges and Where to ...
McKinsey | When Things Get Complex: Complex Systems, Challenges and Where to ...
 
Roche | The Design History File in codeBeamer ALM: Electronic Records, Signat...
Roche | The Design History File in codeBeamer ALM: Electronic Records, Signat...Roche | The Design History File in codeBeamer ALM: Electronic Records, Signat...
Roche | The Design History File in codeBeamer ALM: Electronic Records, Signat...
 
Cosylab | codeBeamer ALM as a Swiss Army Knife on a Particle Therapy Project
Cosylab | codeBeamer ALM as a Swiss Army Knife on a Particle Therapy ProjectCosylab | codeBeamer ALM as a Swiss Army Knife on a Particle Therapy Project
Cosylab | codeBeamer ALM as a Swiss Army Knife on a Particle Therapy Project
 
Adesso | Principles of Tool Validation and Infrastructure Qualification using...
Adesso | Principles of Tool Validation and Infrastructure Qualification using...Adesso | Principles of Tool Validation and Infrastructure Qualification using...
Adesso | Principles of Tool Validation and Infrastructure Qualification using...
 
Automotive SPICE Level 3 and Beyond with codeBeamer ALM
Automotive SPICE Level 3 and Beyond with codeBeamer ALMAutomotive SPICE Level 3 and Beyond with codeBeamer ALM
Automotive SPICE Level 3 and Beyond with codeBeamer ALM
 
27 Nov 2019 – Experts Talk: Integrated MedTech Delivery from Requirements thr...
27 Nov 2019 – Experts Talk: Integrated MedTech Delivery from Requirements thr...27 Nov 2019 – Experts Talk: Integrated MedTech Delivery from Requirements thr...
27 Nov 2019 – Experts Talk: Integrated MedTech Delivery from Requirements thr...
 
13 Nov 2019 - Experts Talk: Balancing Innovation, Risks, and Compliance in Me...
13 Nov 2019 - Experts Talk: Balancing Innovation, Risks, and Compliance in Me...13 Nov 2019 - Experts Talk: Balancing Innovation, Risks, and Compliance in Me...
13 Nov 2019 - Experts Talk: Balancing Innovation, Risks, and Compliance in Me...
 

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

  • 1. 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.
  • 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. 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. 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 Qualification 4 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. 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. 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. 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 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 7 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. 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. 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ßnahmen 9 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. 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. Eclipse Demo Camp | Stuttgart | 23.11.2010 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] 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. 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. 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. 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.