Test von sicherheitsrelevanten Anwendungen für ... · IEC 60601-1 Medical electrical equipment -...

Post on 02-Jun-2020

5 views 0 download

Transcript of Test von sicherheitsrelevanten Anwendungen für ... · IEC 60601-1 Medical electrical equipment -...

Test von sicherheitsrelevanten

Anwendungen für eingebettete

Systeme

Dr. Martin Beißer

sepp.med gmbh

Martin.beisser@seppmed.de 2

Überblick

■ Was sind sicherheitsrelevante Systeme

■ Welche Normen gelten

■ Was ist zu tun?

■ Risikoabschätzung

■ Anforderungsverfolgung

■ Toolvalidierung

■ Zusammenfassung

Martin.beisser@seppmed.de

Sicherheitsrelevante Systeme

■ Sicherheitsrelevante Systeme:

■ Systeme deren Ausfall unmittelbar zu einer

Gefahrensituation führt

■ Sicherheitsbezogene Systeme:

■ Systeme, die eingesetzt werden, um die Risiken von

sicherheitsrelevanten Systemen zu vermindern

(Safety)

Nicht gemeint ist:

■ Schutz eines Systems vor beabsichtigten und

unerwünschten Angriffen von außen (Security)

3

Martin.beisser@seppmed.de

Sicherheit (Safety) und Risiko

■ Wann ist ein System sicher ?

■ Ein System ist sicher, wenn es frei von nicht

akzeptablen Risiken ist

■ Was ist ein Risiko?

■ Das Risiko berechnet sich aus der

Wahrscheinlichkeit des Auftretens eines zum

Schaden führenden Ereignisses und dem dabei zu

erwartenden Schaden.

4

Martin.beisser@seppmed.de

Grundlegende Regularien und Normen

■ ISO 61508 – E/E/EP – Geräte

■ Medizin

■ MPG, FDA

■ ISO 14971 (Risikomanagement)

■ SW Automotiv

■ ISO 26262

■ SW Avionik

■ DO-178C/ED-12C

■ SW Bahn

■ EN 50128

5

Martin.beisser@seppmed.de

Das ist nicht alles! Beispiel Medizin (1/3)

90/385/EEC Active Implantable Medical Devices

98/97/EC In Vitro Diagnostic Medical Devices

MDD 93/42/EEC Medical Devices Directive

European directive for medical device manufactures

MPG Medizinproduktegesetz

MPV Medizinprodukteverordnung

MPBetreibV Medizinproduktebetreiberverordnung

MPSV Medizinprodukte-Sicherheitsplanverordnung

6

Martin.beisser@seppmed.de

Medizin: Welche Vorschriften gibt es? (2/3)

ISO 13485 Quality Management System for design and

manufacturing of medical devices

ISO 14971 Risk Management System for medical devices

IEC 62304 Life Cycle Management for medical device software

IEC 62366 Medical devices - Application of usability engineering to

medical devices

IEC 61508 Functional Safety of Electrical/Electronic/Programmable

Electronic Safety-related Systems

IEC 60601-1 Medical electrical equipment - General requirements for

basic safety and essential performance

IEC/TR 80002-1 Guidance on the application of ISO 14971 to medical device

software 7

Martin.beisser@seppmed.de

Medizin: Welche Vorschriften gibt es? (3/3)

FDA 21 CFR 820 Quality System Regulation

FDA 21 CFR 11 Electronic Records and Electronic Signature

Guidances General Principles of Software Validation

Guidance for the Content of Premarket Submissions for

Software Contained in Medical Devices

Process Validation: General Principles and Practices

Part 11, Electronic Records; Electronic Signatures — Scope

and Application

8

Martin.beisser@seppmed.de

Was ist zu tun?

Folie 10

Martin.beisser@seppmed.de

Grundlegendes zum Risikomanagement

■ je höher die potentielle Gefährdung, ...

■ …desto schärfer die Vorgaben

■ erforderlich für Risikomanagement

■ Ermittlung und Bewertung der Risiken

analytisches, strukturiertes Vorgehen

■ ständige Aktualisierung

11

Martin.beisser@seppmed.de

Klassifizierung gemäß MPG

Risiko

sehr hoch

Hoch

mittel

gering

12

Produkt (Beispiele)

Herzschrittmacher

Herzkatheder

Röntgengeräte

Kondome

Ultraschallgeräte

Zahnfüllungen

Fieberthermometer

Rollstühle

III

IIb

IIa

I, I steril, I mit Messfunktion

Martin.beisser@seppmed.de

Risikoklassen in der Medizinbranche

■ Die Risikoklassen werden bestimmt durch:

Zweckbestimmung

– Beispiel: Defibrillator, Infusionspumpen

Schweregrad

Wahrscheinlichkeit des Auftretens

Entdeckungswahrscheinlichkeit (GAMP)

– Beispiel: Dosier-Einheit

Folie 13

Martin.beisser@seppmed.de

Klassifizierung gemäß ISO 26262

Risiko

sehr hoch

hoch

mittel

gering

14

Produkt - Beispiele

Bremsen

Start-Stop

ESP

Klimaanlage

D

C

B

A

Martin.beisser@seppmed.de

Risikoklassen in der Automotiv-Branche

■ Die Risikoklassen werden bestimmt:

■ Schweregrad

■ Wahrscheinlichkeit des Auftretens

■ Kontrollierbarkeit

Folie 15

Martin.beisser@seppmed.de

Klassifizierung gemäß ISO 26262

Folie 16

ISO 26262: 7.4.5.2 Estimation of potential severity

Martin.beisser@seppmed.de

Klassifizierung gemäß ISO 26262

Folie 17

Martin.beisser@seppmed.de

Klassifizierung gemäß ISO 26262 für Bremse

Folie 18

Martin.beisser@seppmed.de

Dauerhafter (>2 Wochen) Ausfall der Stromversorgung

für AKW

Folie 19

Martin.beisser@seppmed.de

SIL nach IEC/EN 61508

Folie 22

Martin.beisser@seppmed.de

SIL nach IEC/EN 61508

23

Martin.beisser@seppmed.de

Vergleich IEC EN 61508 SIL mit ISO CD 26262 ASIL

Folie 24

Seminar Sommersemester 2009 Automotive Konzepte und Techniken

Prof. Dr. Dieter Z•obel, Universit•at Koblenz-Landau, FB Informatik

Niedrige

Anforderungsrate

Hohe

Anforderungsrate

Martin.beisser@seppmed.de

Konkrete Empfehlungen

Folie 25

ISO 26262-6: 8.4 Requirements and recommendations

Martin.beisser@seppmed.de

Konkrete Empfehlungen

Folie 26

ISO 26262-6: 8.4 Requirements and recommendations

Martin.beisser@seppmed.de

Was ist zu tun ?

Folie 27

Martin.beisser@seppmed.de

Anforderungsverfolgung auf Testfallebene

Folie 28

Testfalldesign

Tracing

Req.-Tool Entw.-

Umgebung

Test-

management

Tracing

Code

Martin.beisser@seppmed.de

Manuelle Verknüpfung der Anforderungen

?

?

?

Testidee Anforderungen

Test Ausführung

Testfälle Tracing

Wartungsaufwand

Folie 29

Martin.beisser@seppmed.de

Anforderungsverfolgung im Test

■ Probleme:

■ Jede Anforderung muss mit N

Testfällen/Testschritten verbunden werden

■ Für automatische Tests muss zusätzlich die

Testspezifikation gepflegt werden

■ Änderungen führen zu massivem Aufwand

Folie 30

Automatische Anforderungsverfolgung?

Martin.beisser@seppmed.de

Autom. Anforderungsverfolgung mit .mzT

Folie 31

Martin.beisser@seppmed.de

Anforderungsverfolgung mit Modellen

START

waitForVelocityVal

STOP

VelocityOK

VelocityTooLow

VelocityTooHigh

ChangedVelocity

InvalidVelocity

changeVelocity( + )changeVelocity( - )

ErrorExit

receiveVelocityVal( 00.95 )

receiveVelocityVal( 00.40 )

receiveVelocityVal( 01,10 )

receiveVelocityVal( -00.50 )

regTimeout

Anforderung im

Modell verknüpfen

Testmodell

automatisch

Testfall

Testfälle mit

Tracing generieren

Test Ausführung

Test-

management

Testfälle + Req. im

Testmanag. verknüpfen

Folie 33

Martin.beisser@seppmed.de

Werkzeugkette für Anforderungsverfolgung

Folie 34

Martin.beisser@seppmed.de

Was ist zu tun ?

Folie 35

Martin.beisser@seppmed.de

Branchenübergreifende Forderung

■ IEC 61508-3 Abschnitt 7.4.4.6

■ “For each tool in class T3, evidence shall be available that the tool conforms to its specification or documentation.”

Folie 36

Martin.beisser@seppmed.de

Werkzeugunterstützung

■ ISO 26262-8 Abschnitt 11

■ “The objective of the qualification of software tools is

to provide evidence of software tool suitability for use

when developing a safety-related item or element,

such that confidence can be achieved in the correct

execution of activities and tasks required by ISO

26262.”

Folie 37

Martin.beisser@seppmed.de

Werkzeugvalidierung FDA

21 CFR 820.70 (i) Automated processes

When computers or automated data processing

systems are used as part of production or the quality

system, the manufacturer shall validate computer

software for its intended use according to an

established protocol.

All software changes shall be validated before

approval and issuance.

These validation activities and results shall be

documented.

38

Martin.beisser@seppmed.de

dokumentierte Werkzeug-Validierung

21 CFR 820.70 (i) Automated processes

When computers or automated data processing

systems are used as part of production or the quality

system, the manufacturer shall validate computer

software for its intended use according to an

established protocol.

All software changes shall be validated before

approval and issuance.

These validation activities and results shall be

documented.

39

Martin.beisser@seppmed.de

Prozessbeschreibung

21 CFR 820.70 (i) Automated processes

When computers or automated data processing

systems are used as part of production or the quality

system, the manufacturer shall validate computer

software for its intended use according to an

established protocol.

All software changes shall be validated before

approval and issuance.

These validation activities and results shall be

documented.

40

Martin.beisser@seppmed.de

Validierungs-Testspezifikation

FDA: 21 CFR 820.70 (i) Automated processes

When computers or automated data processing

systems are used as part of production or the quality

system, the manufacturer shall validate computer

software for its intended use according to an

established protocol.

All software changes shall be validated before

approval and issuance.

These validation activities and results shall be

documented.

41

Martin.beisser@seppmed.de

Änderungskontrolle und Re-Validierung

21 CFR 820.70 (i) Automated processes

When computers or automated data processing

systems are used as part of production or the quality

system, the manufacturer shall validate computer

software for its intended use according to an

established protocol.

All software changes shall be validated before

approval and issuance.

These validation activities and results shall be

documented.

42

Martin.beisser@seppmed.de

Tool-Validierung – was ist zu tun

■ erst denken, dann handeln (=> Planung aller

Aktivitäten),

■ Ergebnisse permanent überprüfen (=> Reviews,

Tests, Validierung),

■ immer dokumentieren, und – ganz wichtig –

■ alles so festhalten, dass es auch später noch und

durch unbeteiligte Dritte nachvollziehbar ist.

43

Martin.beisser@seppmed.de

Tipp 1: methodischer Ansatz

Werkzeug-Validierung

■ Workflow-basiert

■ Validierung gemäß dem „intended use“

■ Anforderungen an das Werkzeug werden aus Use

Cases abgeleitet

■ Modell-basiert

■ graphische Beschreibung der Abläufe

■ gleichzeitig Testdesign-Modell für die Validierung

■ Risiko-basiert

■ vertiefte Tests dort, wo Einfluss auf Produktqualität

möglich

44

Martin.beisser@seppmed.de

Zusammenfassung

Folie 45

Martin.beisser@seppmed.de 46

Testprozess (Beispiel)

Martin.beisser@seppmed.de 47

Domänen-spezifische Anforderungen (I)

Test Engineering

■ Werkzeug-unterstützte Traceability

(zum Nachweis der Vollständigkeit)

■ 100% verlässlich

■ gegen Veränderungen geschützt

■ Review und Freigabe der Testfälle

■ mit Unterschriften

Martin.beisser@seppmed.de 48

Domänen-spezifische Anforderungen (II)

Test Planung

■ Nachweis der Vollständigkeit

■ kein Testfall vergessen

■ Dokumentation der Planung

■ auch für Langzeitarchiv

■ Aussage über Testabdeckung

■ Requirements-Coverage

■ Pfadabdeckung

Martin.beisser@seppmed.de 49

Domänen-spezifische Anforderungen (III)

Test Durchführung

■ nur freigegebene Testfälle

■ gegen Veränderungen geschützt

■ Dokumentation der Ergebnisse

■ inkl. der einzelnen Testschritte

■ mit Unterschrift

■ Nachvollziehbarkeit von Defects

■ keine Änderungen nach Abschluss möglich

Martin.beisser@seppmed.de 50

Domänen-spezifische Anforderungen (IV)

Test Dokumentation

■ Traceability Matrix

■ alle Anforderungen und Risiken

■ zu Testergebnissen

■ Test Summary Report

■ dokumentiert Testplanung und –ergebnisse

■ verweist auf Defects

■ Langzeitarchivierung

Vielen Dank für Ihre Aufmerksamkeit.

Tel.: +49 (0) 91 95 - 9 31 - 0

Fax: +49 (0) 91 95 - 9 31 - 300

E-Mail: martin.beisser@seppmed.de

Web: www.seppmed.de

Martin.beisser@seppmed.de Folie 52

Martin.beisser@seppmed.de 53

Testprozess (Beispiel)

Martin.beisser@seppmed.de 54

Domänen-spezifische Anforderungen (I)

Test Engineering

■ Werkzeug-unterstützte Traceability

(zum Nachweis der Vollständigkeit)

■ 100% verlässlich

■ gegen Veränderungen geschützt

■ Review und Freigabe der Testfälle

■ mit Unterschriften

Martin.beisser@seppmed.de 55

Domänen-spezifische Anforderungen (II)

Test Planung

■ Nachweis der Vollständigkeit

■ kein Testfall vergessen

■ Dokumentation der Planung

■ auch für Langzeitarchiv

■ Aussage über Testabdeckung

■ Requirements-Coverage

■ Pfadabdeckung

Martin.beisser@seppmed.de 56

Domänen-spezifische Anforderungen (III)

Test Durchführung

■ nur freigegebene Testfälle

■ gegen Veränderungen geschützt

■ Dokumentation der Ergebnisse

■ inkl. der einzelnen Testschritte

■ mit Unterschrift

■ Nachvollziehbarkeit von Defects

■ keine Änderungen nach Abschluss möglich

Martin.beisser@seppmed.de 57

Domänen-spezifische Anforderungen (IV)

Test Dokumentation

■ Traceability Matrix

■ alle Anforderungen und Risiken

■ zu Testergebnissen

■ Test Summary Report

■ dokumentiert Testplanung und –ergebnisse

■ verweist auf Defects

■ Langzeitarchivierung

Martin.beisser@seppmed.de 58

Domänen-spezifische Anforderungen (V)

21 CFR Part 11

■ FDA Vorgabe zu „Electronic Records, Electronic

Signature“

■ fordert u.a.

■ Schutz elektronischer Daten vor (böswilliger)

Veränderung

Rechtekonzept, Zugriffschutz

■ bewusste, klar gekennzeichnete Unterschrift mit

mindestens zwei Authentifizierungs-Komponenten

Login und Passwort

■ Audit-Trails

Martin.beisser@seppmed.de 59

Erforderliche Anpassungen im HP QC

■ Audit-Trails / History nicht ausreichend

■ Konfigurations-Management einschalten

■ elektronische Unterschrift nur als Add-On

■ alternativ: Hybridlösung

■ zusätzlicher Schutz von Records via Workflow-

Scripting

■ „Run“ nur für freigegebene Testfälle ermöglichen

■ „Continue“ bei „failed“ Test Runs unterbinden

■ Report-Generierung nach hausinternen Vorlagen

Vielen Dank für Ihre Aufmerksamkeit.

Tel.: +49 (0) 91 95 - 9 31 - 0

Fax: +49 (0) 91 95 - 9 31 - 300

E-Mail: martin.beisser@seppmed.de

Web: www.seppmed.de

Martin.beisser@seppmed.de 61

Das Dilemma

Martin.beisser@seppmed.de 62

methodischer Ansatz

Werkzeug-Validerung

■ Workflow-basiert

■ Validierung gemäß dem „intended use“

■ Anforderungen an das Werkzeug werden aus Use Cases

abgeleitet

■ Modell-basiert

■ graphische Beschreibung der Abläufe

■ gleichzeitig Testdesign-Modell für die Validierung

■ Risiko-basiert

■ vertiefte Tests dort, wo Einfluss auf Produktqualität möglich

Martin.beisser@seppmed.de 63

Bewährte Vorgehensweise (I)

■ 1. Schritt: Analyse

■ Use Cases und Abläufe erfassen ( modell-basierte

Prozessbeschreibung)

■ Risiko- und Part 11 Compliance-Analyse

■ 2. Schritt: Anforderungen ableiten und dokumentieren

■ 3. Schritt (nur bei Ersteinführung): Werkzeug-

Evaluierung

■ gezielte, dokumentierte Auswahl

■ basierend auf vorab ermittelten Anforderungen

Martin.beisser@seppmed.de 64

Bewährte Vorgehensweise (II)

■ 4. Schritt: modell-basierte Testfälle spezifizieren

■ Traceability zu Anforderungen und Risiken im Modell

■ 5. Schritt: Testfälle generieren

■ Priorisierung von Pfaden im Modell

■ Review des Modells möglich

■ 6. Schritt: Validierung durchführen und dokumentieren

■ nicht im noch nicht validierten Werkzeug !

Martin.beisser@seppmed.de 65

Zu theoretisch?

<<2>>

Martin.beisser@seppmed.de 66

Zu theoretisch?

Martin.beisser@seppmed.de 67

Zu theoretisch?

Martin.beisser@seppmed.de 68

Fazit

■ Werkzeuge sind nützlich und nötig

■ Anpassungen sind nötig

■ zur Erfüllung der Domänen-spezifischen Prozessanforderungen

■ Werkzeuge müssen validiert werden

■ bei jeder Änderung

■ die empfohlene Vorgehensweise ist

■ Risiko-basiert

■ Workflow-basiert

■ Modell-basiert

Martin.beisser@seppmed.de

Klassifizierung gemäß ISO 26262

Folie 69

Martin.beisser@seppmed.de

Klassifizierung gemäß ISO 26262

Folie 70

Martin.beisser@seppmed.de

Klassifizierung gemäß ISO 26262

Folie 71