Kategorien: Software & IEC 62304
Tags: , ,

4 Kommentare

  1. Bernd Mark | Freitag, 22. Juni 2018 um 07:36 Uhr - Antworten

    Ein Problem der Systemtests ist die starke Überschneidung mit der IEC60601-1 Kapitel 14.
    Dort wird nun auch für Klasse A eine Software Systemverifizierung für das PESS (bzw. PEMS wenn es kein weiteres PESS gibt) gefordert.

    Bei einem Blackbox test wird man aber in den allermeisten Fällen das PESS brauchen um die Systemsoftware als System zu verifizieren. Wir haben schon bisher die Software intensive über das PESS getestet.

    Nun fordert man von einen weiteren Level Software Systemtest, der aber bei „kleinen“ Systemen mit nur einem Prozessor eigentlich immer das PEMS darstellt.

    Bei Klasse A sollte es möglich sein, das die Software Systemtests und die Verifizierung des PEMS (PESS) in einem durchgeführt werden.
    Es muß Software und Systemanforderungen geben und beide müssen zu 100% getestet werden, aber das sollte in einem Durchlauf möglich sein.


    • Prof. Dr. Christian Johner | Freitag, 22. Juni 2018 um 07:42 Uhr - Antworten

      Sehr geehrter Herr Mark,

      danke für Ihre wertvollen Hinweise.

      Man hat bei der IEC 62304 bewusst die Software-Systemtests bewusst auch für Klasse-A-Softwaresysteme verlangt.

      Weil man eine „isolierte Software“ genauer prüfen kann, als eine in einem Gerät verbaute Software, möchte man die Software-Systemtests nicht (nur) im Rahmen der PEMS-Systemtests durchgeführt wissen. Beispielsweise muss eine Software bestimmte Fehlverhalten der Hardware überprüfen und darauf reagieren können. Im Rahmen von PEMS-Tests lässt sich das meist nicht prüfen.

      Nochmals besten Dank!

      Viele Grüße, Christian Johner


  2. Bernd Mark | Freitag, 22. Juni 2018 um 08:34 Uhr - Antworten

    Hallo Herr Johner,

    Ich gebe ihnen Recht das es Punkt gibt die sich bei einer isolierten Software besser prüfen lassen.
    Diese werden aber auch bisher schon als Whitebox Test oder Code Review beim PEMS Test durchgeführt, weil anders überhaupt nicht testbar.
    Da wir wie gesagt in der PEMS Spezifikation schon jede Menge „Software Requirements haben“.

    Nehmen wir die ca. 60% der Software die sich mit der Anzeige und User Interaktion befassen, die da Sie Klasse A sind nicht kritisch sind.
    Wenn wir alles das einmal im Software System und dann noch mal im PEMS prüfen, ist das ein sehr großer Aufwand mit vergleichsweise wenig zusätzlichem nutzen.

    Wenn man mit der Erweiterung nur festlegen will das man ich hierüber Gedanken machen muß und auch solche Punkte testen muß gebe ich ihnen Recht.

    Aber mit dem „Gießkannenprinzip“ zu sagen es muss nun für alle Requirements ein Software ein Softwaresystemtes zusätzlich her ist doch etwas sehr hoch gegriffen für Klasse A Software.

    Oder muß man die Anforderungen hier nur neu Aufteilen in System und Software und dann eben auf der entsprechenden Ebene Testen.


    • Prof. Dr. Christian Johner | Freitag, 22. Juni 2018 um 09:54 Uhr - Antworten

      Danke für Ihr Nachhaken, Herr Mark!

      Meine Aussage war nicht, dass Sie die Anforderungen an das Software-System ausschließlich über Software-Systemtests prüfen müssen. Wenn Sie dort auf PEMS-Tests verweisen, wie beispielsweise bei der UI, dann ist das konform (Einschränkungen s.u.).

      Umgekehrt ist es möglich, im Software-Systemtest auf Testergebnisse aus vorausgegangenen Testphasen zu verweisen. Beispielsweise ließe sich die korrekte Implementierung einer UI (statische Aspekte) bereits bei der Prüfung der UI-Komponente prüfen. Deren korrekte Anbindung an das Backend wäre wiederum ein Aspekt von SW-Integrations- oder SW-Systemtests.

      Die Anforderungen, dass alle Software-Anforderungen überprüft wurden — gleich im Rahmen welcher Aktivität — bleibt aber unbenommen. Ob das bei Klasse A immer sinnvoll ist, lässt sich diskutieren.

      Meine Empfehlung wäre, die Anforderungen immer möglichst früh zu prüfen. Andernfalls wäre es beispielsweise nicht möglich, die Software-Freigabe zu erteilen, bevor die Systemtests abgeschlossen sind. Das würden den ganzen Entwicklungsprozess konterkarieren.

      Beste Grüße, Christian Johner


Hinterlassen Sie einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.