Sprachen
Seiten
Rechtliche
Test von sicherheitsrelevanten
Anwendungen für eingebettete
Systeme
Dr. Martin Beißer
sepp.med gmbh
Überblick
■ Was sind sicherheitsrelevante Systeme
■ Welche Normen gelten
■ Was ist zu tun?
■ Risikoabschätzung
■ Anforderungsverfolgung
■ Toolvalidierung
■ Zusammenfassung
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
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
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
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
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
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
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
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
Risikoklassen in der Medizinbranche
■ Die Risikoklassen werden bestimmt durch:
Zweckbestimmung
– Beispiel: Defibrillator, Infusionspumpen
Schweregrad
Wahrscheinlichkeit des Auftretens
Entdeckungswahrscheinlichkeit (GAMP)
– Beispiel: Dosier-Einheit
Folie 13
Klassifizierung gemäß ISO 26262
Risiko
sehr hoch
hoch
mittel
gering
14
Produkt - Beispiele
Bremsen
Start-Stop
ESP
Klimaanlage
D
C
B
A
Risikoklassen in der Automotiv-Branche
■ Die Risikoklassen werden bestimmt:
■ Schweregrad
■ Wahrscheinlichkeit des Auftretens
■ Kontrollierbarkeit
Folie 15
Klassifizierung gemäß ISO 26262
Folie 16
ISO 26262: 7.4.5.2 Estimation of potential severity
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
Anforderungsverfolgung auf Testfallebene
Folie 28
Testfalldesign
Tracing
Req.-Tool Entw.-
Umgebung
Test-
management
Tracing
Code
Manuelle Verknüpfung der Anforderungen
?
?
?
Testidee Anforderungen
Test Ausführung
Testfälle Tracing
Wartungsaufwand
Folie 29
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?
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
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
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
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
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
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
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
Ä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
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
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
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
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
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
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: [email protected]
Web: www.seppmed.de
[email protected] Folie 52
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
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
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
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
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
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: [email protected]
Web: www.seppmed.de
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
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
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 !
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
Top Related