test von sicherheitsrelevanten anwendungen für ... · iec 60601-1 medical electrical equipment -...
Post on 02-Jun-2020
5 Views
Preview:
TRANSCRIPT
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
top related