Neue Anforderungen an Tools

Ähnliche Dokumente
Validierung von Software-Werkzeugen Medical Device Day, Dipl.-Phys. Matthias Hölzer-Klüpfel, M.Sc.

Der Einsatz von Open Source Tools für Safety und Security

Nachts ist s kälter als draußen Warum qualifizieren und nicht zertifizieren?

I-Q SCHACHT & KOLLEGEN QUALITÄTSKONSTRUKTION GMBH ISO 26262:2011. Tabellen mit ASIL Zuordnungen

I-Q SCHACHT & KOLLEGEN QUALITÄTSKONSTRUKTION GMBH ISO 26262:2011. Tabellen mit ASIL Zuordnungen

Abbildung 1: Tool-Qualification-Kits für Testwell CTC++ Test Coverage Analyser

Tool Qualifikation. Schreckgespenst der Testautomatisierung? HEICON Global Engineering Kreuzweg 22, Schwendi

Stand der Überarbeitung in der IEC SC 65A/MT , Vorbereitung 3. Ausgabe der IEC GAK Frankfurt,

Generische Normen zur Funktionalen Sicherheit im Maschinenbau. IEC und ISO 13849

Funktionale Sicherheit: Wie macht man das? Andreas Stucki, Solcept AG

ISO / FuSi Funktionale Sicherheit Road Vehicle - Functional Safety

Funktionale Sicherheit und Simulation

Testen von sicherheitskritischer Embedded Software mit frei verfügbaren Tools. - ein Erfahrungsbericht

Sicherheitsgerichtete Anwendersoftware SRASW. Verifikation und Validierung nach DIN EN ISO /2

Kontakt: Tel

Openinterface Impuls Eine kurze Vorstellung. Openinterface, J. Friebe, KISTERS AG, J. Jordan, IDS GmbH, E. Herold, PSI Software AG

ISO / FuSi Funktionale Sicherheit Road Vehicle - Functional Safety

Funktionale Sicherheit in Automotive und Luftfahrt (ISO26262 und DO 178BC) Otto Alber, Peter Wittmann

Sicherheitsnormen im Umbruch Revision der EN 5012X-Suite

Assessment der Funktionalen Sicherheit

Management Hardware Software

DIN EN (VDE ): EN 62304: A1:2015

Anforderungen zur Entwicklung von E-CAD-Systemen

Anforderungen gezielter umsetzen, Optimieren, Transparenz schaffen

Vortrag IHK. CE Kennzeichnung von Medizinprodukten. Umsetzung der Dokumentation Thomas Bohnen Qualitätsplan

Anlage zur Akkreditierungsurkunde D-PL nach DIN EN ISO/IEC 17025:2005

Validierung von Software-Werkzeugen. Matthias Hölzer-Klüpfel

VDMA Funktionale Sicherheit Universelle Datenbasis für sicherheitsbezogene Kennwerte von Komponenten oder Teilen von Steuerungen

Mit den 5 Prinzipien der Lebendigkeit für Anforderungen komplexe Systeme meistern. Dr.-Ing. Thaddäus Dorsch, HOOD GmbH,

ISO Reference Model

Beratung & Coaching. Jede Lösung beginnt mit einer Frage

Radikaler Umbruch in der Fahrzeug- und Systemabsicherung. Steffen Kuhn

Normerfüllung in der Praxis am Beispiel "Tool Qualification" Dr. Anne Kramer, sepp.med gmbh

ABSICHERUNG MODELLBASIERTER SICHERHEITSKRITISCHER AVIONIK SOFTWARE Dr. Elke Salecker

Projektmanagement und Softwareentwicklung. Nina Stodolka, WS2017/2018

Specmate Auf Knopfdruck von Anforderungen zu Tests

Aktuelle Herausforderungen der Automobil-Industrie beim Rollout der ISO Polarion Live User Conference 2013 Heiko Lerch, ITK Engineering AG

Fred Stay /05. Management der Funktionalen Sicherheit KROHNE Academy Automatisierungstechnik in der Prozessindustrie

Integration von Change- und Projektmanagement mit ITIL v3

Comparing Software Factories and Software Product Lines

Visual Studio 2010 Neues für Architekten

Präsentation DIN-EN 81-1/A1: 2005 DIN-EN 81-2/A1: 2005 (PESSRAL) 15. Juni 2008 VI. Schwelmer Liftsymposium

Agile Softwareentwicklung im normativ regulierten Umfeld: Die Rolle der Qualitätssicherung für eine Zertifizierung

Systemdenken und Gestaltungsmethodik Dokumentation

IT-Projekt-Management

Einladung zu den Safety Integrated Workshops.

Checkliste ISO/IEC 27001:2013 Dokumente und Aufzeichnungen

Am Beispiel eines international tätigen Automotive Lieferanten

Wesentliche Änderung EN 9100:2016 / EN 9120: München/Hamburg Michael Rotzsche/ Wolfgang Bott

Requirements-basiertes Testen am Beispiel des NI Requirements Gateways

Von Requirements zutests. gç~åüáãkpåüìäò]èì~äáíóé~êâkçé

Anforderungen, KEFs und Nutzen der Software- Prozessverbesserung

ISO Reference Model

Agilität trifft Funktionale Sicherheit

Was geht Qualitätsmanagement/ Qualitätsicherung die Physiotherapeutenan? Beispiel einer zertifizierten Abteilung

Dienstag, 24. September 13. Willkommen

Einführung in die ISO 26262

EJB City GmbH ist Ihr Partner dafür!

DOORS Schema IBM Rational DOORS Start-Up Training - Teil 3

Systemvalidierung der Studiensoftware eresearch Network am Koordinierungszentrum für f r Klinische Studien DüsseldorfD. Dimitrios Venizeleas

Functional Safety. Systems Engineering als Schlüsseldisziplin in Projekten mit funktionaler Sicherheit

MOBILE ON POWER MACHEN SIE IHRE ANWENDUNGEN MOBIL?!

Welche Testautomatisierungen sind möglich und sinnvoll?

Benutzerorientierte Entwicklung mobiler Anwendungen

Methodische und konzeptionelle Hinweise zur Entwicklung einer IVS-Rahmenarchitektur Straße für Deutschland

Türen Tore (TuT) Technische Richtlinie. Änderungsdokument freigegeben öffentlich PLaPB

How to Survive an Audit with Real-Time Traceability and Gap Analysis. Martin Kochloefl, Software Solutions Consultant Seapine Software

Komplexität beherrschen mit Contract Based Design

ÄNDERUNGEN UND SCHWERPUNKTE

Norm Revision ISO 9001:2015. Konsequenzen für Unternehmung, Prozesseigner und Auditoren

Agile Software-Entwicklung im Kontext der EN50128 Wege zum Erfolg

Tunnel - Lüftung (TLü)

Uniper Anlagenservice GmbH

Tunnel - Lüftung (TLü)

Fachforum 5: Systems Engineering Modellgetriebene Entwicklung von Schrittketten G. KRAFT Maschinenbau GmbH 06. Dezember 2017 Paderborn

Entwicklung Safety-relevanter Steuergeräte auf Basis des V-Modells

Requirements basiertes Testen mit JUnit Architektur für eine Verbindung von Requirements Management und Test Management

Erfahrungen der. DQS GmbH. bei der Zertifizierung von Medizinprodukteherstellern

Darstellung und Anwendung der Assessmentergebnisse

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH

Tunnel - Funk (TFu) Änderungsdokument freigegeben öffentlich PLaPB. Planungshandbuch der ASFiNAG

ISO 13485:2016. TÜV SÜD Akademie GmbH Rev. <xx > / Stand: EN ISO 13485:2016 1

TFS als ALM Software. Erfahrungsbericht aus der MedTec Ecke. Lukas Müller

MOBILE ENTERPRISE APPLICATION PLATFORM (MEAP)

Software-Entwicklung sicherheitskritischer Systeme. Das SEHB im Safety Management System der DFS Dr. Jörg Brachmann

ITIL Prozese in APEX am Beispiel des Vodafone FCH

Auswirkungen der ISO auf die Strukturen von Requirements- und Test- Datenbanken während der Entwicklung

ISO 29119: Die neue Normenreihe zum Softwaretest

Unternehmensdokumente mit dem XML Publisher erzeugen

Business Analysis Body of Knowledge BABOK v3. Konzepte Scope Struktur. Ursula Meseberg microtool GmbH Berlin

VDMA Funktionale Sicherheit Universelle Datenbasis für sicherheitsbezogene Kennwerte von Komponenten oder Teilen von Steuerungen

Transkript:

Stand der Arbeiten zur Tool Qualifizierung in der IEC SC 65A WG3 GAK 914.0.3 Frankfurt, 22.02.2017 1

Warum soll es neue Anforderungen an Tools geben? Bedingt durch komplexere Systeme, kürzeren Entwicklungszyklen bei gleichzeitig hohen Qualitätsanforderungen und hohem Kostendruck steigt die Verwendung von Tools für die Entwicklung und Verifikation zunehmend. Was ist heute zu Tools in der IEC 61508 gefordert? IEC 61508-3:2010 7.4 Softwaredesign and development 7.4.4 Requirements for support tools, including proramming languages Es werden nur eingeschränkte Anforderungen in Kap. 7.4.4. dargestellt. Ende 2014 wurde eine Arbeitsgruppe von SC65A WG3 beauftragt ein IP (Information paper) zur Tool Qualifizierung zu erstellen, das sowohl die Entwicklung von Tools als auch die Anwendung von Tools berücksichtigt. 2

Anforderungen zur Tool Qualifizierung aus der Deutschen Arbeitsgruppe GAK 914.0.3 Die überarbeitete Version soll berücksichtigen: Auswahl an Maßnahmen die im Rahmen der Toolqualifizierung umzusetzen sind, in Abhängigkeit von der Auswirkung potentieller Toolfehler und dem SIL Definition von Maßnahmen die im Rahmen der Toolqualifizierung umzusetzen sind, wenn die Toolqualifizierung hauptsächlich auf der Tool-Entwicklung basiert. Eine eindeutige Identifikation und Beschreibung der Toolfunktionalität, die in der Toolqualifizierung betrachtet wurde. Programmiersprachen sollen in einem separaten Kapitel behandelt werden 3

Anforderungen zur Tool Qualifizierung aus der Deutschen Arbeitsgruppe GAK 914.0.3 Eine funktionsorientierte Analyse der potentiellen Toolfehler mit den erforderlichen Maßnahmen diese Fehler zu beherrschen. Auf Basis dieser Fehleranalyse soll vom Tool Hersteller folgendes bereitgestellt werden: Eine Toolqualifizierung Information an den Anwender über die potentiellen Toolfehler, die nicht oder nur teilweise beherrscht werden. Bereitstellen von Regeln, wie die nicht oder nur teilweise beherrschten Toolfehler behandelt werden können Bereitstellung eines vom Anwender zugreifbaren Problemmeldungsverfahrens Felderfahrung alleine ist nicht ausreichend, Felderfahrung zusammen mit anderen Maßnahmen wird erwartet (Bsp. Toolvalidation) Die Anforderungen an Tools gelten unabhängig von der Anwendung des Tools auf Software-, Hardware-, Systemebene 4

Was wurde bisher erarbeitet? Das IP wurde von einer internationalen Arbeitsgruppe erarbeitet Das IP wurde 2 mal zur Kommentierung an die nationalen Komitees versandt Alle Kommentare wurden bewertet und eingearbeitet Das aktuelle IP mit der Rev. 6 wird im April 2017 bei der nächsten SC65A WG3 Sitzung weiter besprochen Bei der Erarbeitung des IP wurden auch andere Normen betrachtet, die ebenfalls das Thema Tool Qualifizierung behandeln, z.b. Automotive: ISO 26262 Avionic: DO 178C / DO330 um insbesondere Konflikte zu diesen Normen zu vermeiden 5

Inhalt des Information Papers (IP) 6

Inhalt des Information Papers (IP) 7

Allgemein: Tool Qualification wird ersetzt durch Confidence in use of offline support tools Der Inhalt dieses IPs soll den Teil IEC61508-3 7.4.4 Requirements for support tools ersetzen und in ein neues Kapitel kommen oder zunächst eine Technische Spezifikation werden. Der Teil programming languages wird separat behandelt. Scope: Das IP behandelt ausschließlich offline support tools. Online support tools müssen als Element des Sicherheitssystemes behandelt werden. Ziel: Tools können für die Automatisierung von Entwicklungs- und / oder Verifikationsaufgaben von Sicherheitsfunktionen eingesetzt werden. Dies hat einen hohen Nutzen in Bezug auf die Produktivität und Qualität. Tools können aber auch Fehler in ein Systems einbringen (Bsp. Code Generatoren) oder bestehende Fehler in der Software nicht erkennen (Test Tools). Ziel der beschriebenen Maßnahmen ist, dass Tools so ausgewählt, entwickelt und angewandt werden, dass diese die Sicherheitsziele einer Funktion nicht negativ beeinflussen. 8

Kenngrößen SIL TI TD TIL Safety Integrity Level (SIL1 SIL4) Tool Error Impact (TI1 - TI3) Tool Error Impact Detection / Prevention Level (TD1 TD3) Tool Integrity Level (TIL0 TIL4) 9

Vorgehensweise Tool planning Tool Characterization Tool usage Tool Integration and validation Tool Operation Required TIL User requirement Existing tool? No Yes Tool exec Tool doc Tool limitations Tool development and maintenance 10

Anmerkungen zum Vorgehen Anmerkungen: Das Tool kann für eines früheres Projekt entwickelt worden sein, kann ein COTS Tool sein oder auch für die spezielle Anwendung entwickelt worden sein. Das Tool kann vom Anwender entwickelt werden oder von einer externen Firma (z.b. fertig zertifiziert) zugekauft werden. Tool Planung und Tool Charakterisierung: Der Anwender muss sich vor einer Tool-Anwendung überlegen: - welche Sicherheitsanforderungen in der Applikation zu erfüllen sind (SIL). - welchen Einfluss die Verwendung eines /mehrerer Tools (Tool Chain) haben kann (TI) - was das zu verwendende Tool hinsichtlich Tool Qualifizierung erfüllt / erfüllen soll (TIL) und - was er als Tool-Anwender noch tun muss um das Sicherheitsziel zu erreichen (TD). 11

Zusammenhang der Kenngrößen Tool Confidence Principle 12

Erläuterungen zum Bild Tool Confidence Principle Beispiel1 Für einen gegebenen TI, SIL, TIL kann der erforderliche TD ermittelt werden. Beispiel 2 Wenn eine vollständige Verifikation des Tool Outputs durchgeführt wird, wird kein qualifiziertes Tools benötigt. Beispiel 3 Es wird ein qualifiziertes Tool verwendet um die Notwendigkeit einer Verifikation des Tool Outputs zu reduzieren. 13

Tool Error Impact (TI) TI1: Tool Fehler haben keinen Einfluss auf die entwickelte ausführbare Sicherheitsfunktion TI2: Das Tool kann versagen einen Fehler zu erkennen, kann aber keine Fehler in der ausführbaren Sicherheitsfunktion erzeugen (Bsp. Test Tool) TI3: Das Tool kann Fehler in der entwickelten ausführbaren Sicherheitsfunktion erzeugen (Bsp. Codegenerator) 14

Tool Error Detection / Prevention Level (TD) Charakterisiert den Grad der Wirksamkeit von Maßnahmen extern des Tools (Bsp. Review des Tool Outputs) TD3: Verwendung eines nicht qualifizierten Tools. Erkennung jede Art von Toolfehlern durch systematische Maßnahmen extern des Tools basierend auf systematischen Maßnahmen entsprechen IEC 61508-3 Bsp. Der generierte Code eines Codegenerators wird einem umfassenden Review unterzogen TD2: Erkennung jede Art von Toolfehlern durch indirekte Maßnahmen basierend auf systematischen Maßnahmen entsprechend IEC 61508-3 Bsp. Der Source Code eines Codegenerators ist nicht verifiziert, aber umfassende Modultests werden durchgeführt TD1: Hohes Vertrauen in das Tool, da ein qualifiziertes Tool verwendet wird. Bsp. Ein zertifizierter Codegenerator wird verwendet. Der generierte Code wird keinem Review unterzogen, Modultests werden nicht durchgeführt Achtung: Funktionstests als Nachweis, dass alle Sicherheitsanforderungen erfüllt sind können nicht weggelassen werden! 15

Tool Integrity Level (TIL) Definiert den Grad der Tool Qualifizierung um in Verbindung mit dem TD einen geforderten SIL für die Applikation zu erreichen. TIL0 - keine Tool Qualifizierung... TIL4 - Höchste Tool Qualifizierung entsprechend einer Sicherheitsnorm z.b. IEC 61508 SIL4 oder DO 330 SW-Level A, TQL1 17

Abhängigkeiten der Kenngrößen TD SIL TIL for TI3 tool 3 Any 0 0 2 1 0 0 2 2 1 0 2 3 2 1 2 4 3 2 1 1 1 0 1 2 2 1 1 3 3 2 1 4 4 3 TIL for TI2 tool 18

1.3.3 Tool Integration und Validierung in die Anwendungsumgebung - Der Anwender muss die Tool Dokumentation lesen und prüfen ob das Tool die Anforderungen erfüllt - Vertrauen in Betriebsbewährung eines Tools ist auf TIL 1 begrenzt 1.3.4 Tool Konfigurationsmanagement im Anwender Umfeld - Konfigurationsmanagement ist sowohl anwenderseitig als auch entwicklungsseitig vorzusehen - Aktualisieren von Tools erfordert eine Auswirkungsanalyse - Management aller bekannter Tool Fehler und Tool Einschränkungen. Für jeden Tool Fehler ist eine Einflussanalyse durchzuführen und geeignete Detection / Prevention - Maßnahmen abzuleiten und zu dokumentieren 1.3.5 Tool Einsatz - Angemessene Kompetenz und angemessene Schulung des Anwenders ist gefordert 19

Vorgehensweise Tool planning Tool Characterization Tool usage Tool Integration and validation Tool Operation Required TIL User requirement Existing tool? No Yes Tool exec Tool doc Tool limitations Tool development and maintenance 20

Tool Entwicklungs Aktivitäten Das Kapitel 1.4 definiert Anforderungen für die Tool Entwicklungs- / Verifikations-Aktivitäten abhängig vom Tool Integrity Level (TIL) Die minimale Nachweisführung zur Erreichung eines TIL1 TIL4 ist in Tabelle 5 dargestellt Für TIL3 und TIL4 wird empfohlen die Nachweisführung basierend auf einem Sicherheitsstandard ( z.b. IEC 61508, DO330) durchzuführen. 21

Required confidence evidence in relation to the TIL Required confidence evidence TIL-0 TIL-1 TIL-2 TIL-3 TIL-4 1 Tool user documentation (1.4.6) HR HR HR HR HR 2a Tool validation [against written requirements] (1.4.5) - - R HR HR 2b Confidence from tool usage history (1.3.3.2) - HR R R R 3 Tool development plan (1.4.2) - - - R R 4 Tool requirements (1.4.3) - - R HR HR 5 Tool architecture documentation (1.4.4) - - - R HR 6 Tool detailed design traced to tool requirements (1.4.4) - - - - HR 7 Source code traced to detailed design (1.4.4) - - - - HR 8 Tool module test report incl. design coverage (1.4.4) - - - - HR 9 Structural coverage (MC/DC) (1.4.4) - - - - HR 10 Tool development and verification achievement - - - R HR summary (e.g. Safety Case, Tool Accomplishment Summary) 11 Tool configuration management (1.4.7) - - - R HR 12 Tool defect management (1.4.7) - - - R HR 13 External components identification and integration - - - HR testing (1.4.9) R 22

1.4.2 Tool Entwicklungsplanung 1.4.3 Tool Anforderungen 1.4.4 Tool Design, Implementierung, und Verifikation 1.4.5 Tool Validation 1.4.6 Tool Dokumentation Alle Offline Support Tools müssen eine Spezifikation oder eine Anwender Dokumentation haben in der das Verhalten und alle Vorgaben und Einschränkungen für die Verwendung des Tools eindeutig beschrieben sind 1.4.7.Tool Konfigurations Management 23

1.4.8 Tool Fehler Management Fehler, die bei der Fehleranalyse oder durch Anwenderberichte bekannt sind und nicht oder nur teilweise vom Tool beherrscht werden müssen an den Anwender kommuniziert werden. Die Dokumentation soll den Anwender in die Lage versetzen den Einfluss auf sein System zu bewerten zu können. Der Tool Entwickler muss dem Anwender eindeutige Regeln zu Verfügung stellen, wie solche Fehler, vom Anwender beherrscht werden können. Der Tool Entwickler muss ein Problemverfolgungssystem unterhalten auf das der Anwender Zugriff hat (user accessible problem tracking system). Dieses Problemverfolgungssystem muss in das Änderungsmanagement des Tool Entwicklers integriert sein. 1.4.9 Externe Komponenten 24

Weiterer Hinweis zum Tool Management Für IEC 61508-1 liegt ebenfalls ein Vorschlag für ein neues Kapitel Tool-Management von Offline Support Tools vor. Die beiden Vorschläge zum Thema Tools müssen zwischen den beiden Arbeitsgruppen IEC 61508 Teil 1 & 2 und Teil 3 besprochen werden. 25

Vielen Dank für Ihre Aufmerksamkeit! Norbert Fröhlich Pilz GmbH & Co.KG Leiter Entwicklung Produkte DKE Deutsche Kommission Elektrotechnik Elektronik Informationstechnik im DIN und VDE Stresemannallee 15 D-60596 Frankfurt/Main Telefon: +49 69 6308-226 E-Mail: xxx.xxx@vde.com http://www.dke.de