Neue Anforderungen an Tools

Transkript

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

2 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 gefordert? IEC : Softwaredesign and development Requirements for support tools, including proramming languages Es werden nur eingeschränkte Anforderungen in Kap 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

3 Anforderungen zur Tool Qualifizierung aus der Deutschen Arbeitsgruppe GAK 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

4 Anforderungen zur Tool Qualifizierung aus der Deutschen Arbeitsgruppe GAK 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

5 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 Avionic: DO 178C / DO330 um insbesondere Konflikte zu diesen Normen zu vermeiden 5

6 Inhalt des Information Papers (IP) 6

7 Inhalt des Information Papers (IP) 7

8 Allgemein: Tool Qualification wird ersetzt durch Confidence in use of offline support tools Der Inhalt dieses IPs soll den Teil IEC 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

9 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

10 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

11 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

12 Zusammenhang der Kenngrößen Tool Confidence Principle 12

13 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

14 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

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

16 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 SIL4 oder DO 330 SW-Level A, TQL1 17

17 Abhängigkeiten der Kenngrößen TD SIL TIL for TI3 tool 3 Any TIL for TI2 tool 18

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 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 Tool Einsatz - Angemessene Kompetenz und angemessene Schulung des Anwenders ist gefordert 19

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

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

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 ( ) - 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

22 1.4.2 Tool Entwicklungsplanung Tool Anforderungen Tool Design, Implementierung, und Verifikation Tool Validation 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 Tool Konfigurations Management 23

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 Externe Komponenten 24

24 Weiterer Hinweis zum Tool Management Für IEC 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 Teil 1 & 2 und Teil 3 besprochen werden. 25

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 Frankfurt/Main Telefon: