Software als Zustandsautomat spezifizieren? Passen Sie auf!

Mittwoch 25. November 2015

Ein Medizinprodukt als Zustandsautomat spezifizieren, weshalb nicht, denke ich, als ich in einer System-Spezifikation lese: „Wenn man über den CAN-Bus das Kommando ‚MPS_0320’ schickt, dann geht die Maschine [das Medizinprodukt] in den Zustand ‚Vorbereiten’“. Doch dann bemerke ich den Haken.

Medizinprodukt als Zustandsautomat spezifizieren

 

Zustandsautomat mit UML-Zustandsdiagramm modelliert

Als Auditor freut man sich über jede halbwegs präzise Spezifikation. Und wenn die als Zustandsautomat sogar grafisch mit einem UML-Zustandsdiagramm modelliert ist, dann müsste eigentlich alles gut sein.

In der Tat, viele Systeme lassen sich als Zustandsautomat modellieren. Beispielsweise kennt eine Maschine Zustände wie

  • In Vorbereitung
  • In  Stand-by
  • Beim Behandeln
  • In Reinigung
  • usw.

Es ist auch klar, dass man nicht jeden Zustand von jedem Zustand aus erreichen darf. Beispielsweise darf es nicht sein, dass die Maschine von einer Behandlung direkt zur nächsten übergeht ohne den Zustand „in Reinigung“ vorher zu durchlaufen. Genau diese möglichen und verbotenen Zustandsübergänge lassen sich als Zustandsautomat modellieren — beispielsweise mit einem Zustandsdiagramm.

Probleme beim Spezifizieren als Zustandsautomat

Das System als Zustandsautomat zu spezifizieren birgt aber auch Tücken: „Wie wollen Sie das testen?“ frage ich meinen Kunden. Nach einigem Überlegen kommt die Antwort, dass man künftig den Zustand über ein weiteres Kommando abfragen wolle.

Passen Sie etwas auf, wenn Sie Ihr Medizinprodukt als Zustandsautomaten beschreiben. Die Systemanforderung bzw. Software-Anforderung ist eine Beschreibung des Systems aus Blackbox-Sicht. D.h. die Systemanforderung (PEMS-Anforderungen/PEMS-Spezifikation) sollte beschreiben, wie die Blackbox an deren Schnittstellen auf Aktionen über deren Schnittstellen reagiert. Ein Zustand ist aber ein internes Verhaltens eines Systems oder einer Komponente.

Auf Zustandsautomaten/-diagramme verzichten?

Damit plädiere ich keinesfalls gegen das Spezifizieren des Systems als Zustandsautomat. Aber spezifizieren Sie die einzelnen Zustände als Kombination von über die Schnittstellen sichtbaren Verhalten. Ein Zustand ist also eher eine Art Makro (wie es die C-Programmierer nennen würden).

Ein Zustand, der nach außen nicht sichtbar ist, hat in einer System- oder Software-Anforderung nichts verloren.

All das Gesagte gilt übrigens für programmierbare elektrische medizinische Systeme PEMS ebenso wie standalone Software wie für Komponenten.

Prof. Dr. Christian Johner
Sind Sie unsicher, ob Sie eine Spezifikation erstellt haben, die gesetzeskonform ist und bei der Zulassung „durchgehen“ wird? Ob die Spezifikation auch hilft, die Entwicklung zu beschleunigen? Professor Johner und sein Team helfen gerne! Nehmen Sie Kontakt auf!

Kategorien: Software & IEC 62304
Tags: ,

4 Kommentare über “Software als Zustandsautomat spezifizieren? Passen Sie auf!”

  1. Ulrich von Knobloch schrieb:

    Sehr geehrter Herr Prof. Johner,
    ich, als Ihr Fan, muss Ihnen in diesem Fall widersprechen. Meine Arbeiten als System Ingenieur beliefern Medizintechnik-Entwicklungen so wie Luft-Und Raumfahrt. Die Validieren und Verifizierung muss das Unternehmen so oder so machen. Meine Erfahrung ist jedoch, dass die klare Darstellung der UML den Vorteil hat, dass man den Überblick behält. Die ausformulierten Anforderungen sind vielleicht auf dem ersten Blick einfacher für das V-Modell zu „tracen“, aber haben wiederum die Gefahr von Inkonsistenzen und Lücken. Von meiner Seite ein ganz klares JA zu UML und menschenfreundliche Anforderungsbeschreibungen.

    Viele Grüße
    Uli von Knobloch

    ps.: Erfahrung bei einer Triebwerkszulassung nach DO-178B / DO-254

  2. Christian Johner schrieb:

    Lieber Herr von Knobloch,

    besten Dank für Ihr wichtiges Feedback! Ich fürchte mich sehr missverständlich ausgedrückt zu haben. Keinesfalls argumentieren ich gegen UML. Im Gegenteil. Ich empfehle standardisierte Notationen im Allgemeinen und UML im Speziellen. Das hoffe ich, in vielen Blog-Beiträgen zum Ausdruck gebracht zu haben.

    In diesem speziellen Beitrag geht es mir nicht um UML, sondern um die Gefahr, mit Zustandsdiagrammen die Spezifikation und die Implementierung zu vermischen. Ich habe leider zu oft gesehen, dass eine Spezifikation einer Blackbox bei Kunden bereits interne Zustände der Blackbox beschrieben hat — aufgrund von (internen) Zustandsautomaten.

    In der Hoffnung, etwas für Klarheit gesorgt zu haben, und mit herzlichen Grüßen
    Christian Johner

  3. Ulrich von Knobloch schrieb:

    Lieber Herr Prof. Johner,

    vielen Dank für die schnelle Reaktion, sie hat bei mir für Klarheit geführt – der Groschen ist jetzt gefallen.

    Jetzt verstehe ich, was Sie meinen, UML könnte verführen auf der System-Ebene schon funktionale Anforderungen zu beschreiben. OK, Sie haben 100% recht. Da müssen wir definitiv aufpassen und uns zum Teil auch beim Kunden durchsetzen, dieser (später teuren) Verführung nicht nachzugehen.

    beste Grüße
    Uli v. Knobloch

  4. Hartmut Petters schrieb:

    Sehr geehrter Herr Prof. Johner,

    ich verstehe ihre Argumentation. Allerdings ist einerseits die Darstellung der SW-Zustände, UML und andererseits die Systemreaktion auf defineirte Signale an den zugänglichen Schnittstellen kein Widerspruch, da sie aus meiner Sicht verschiedene Ebenen des V-Modells und den damit verbundenen Testfällen widerspiegelt.
    Die Systemreaktionen als „Black-Box“ betreffen m.E. die Systemebene, so dass ich zu jeder akzeptierten System-Anforderung auch einen dedizierten Tstfall besschreibe, der genau diese Anforderung als „Black-Box-Test“ abprüft … dies sollte hinreichend für eine Zertifizierung bzw. Validierung + Verifikation auf Systemebene sein.
    Die Beschreibung der internen Systemzustände – zu denen m.E. natürlich auch die Input´s und Output´s der einzelnen Module – z.B. CAN-Treiber – gehören ist für mich im Bereich der Detailspezifikation des Systems anzusiedeln und durch entsprechende Modul- und Teilsystemtests mit geeigneten Hilfsmitteln – sprich Grey- und White-Box-Tests – abzusichern. Auch hier plädiere ich absolut dazu gemeinsm mit der Erstellung der Spezifikation gleichzeitig die Testfälle zu spezifizieren, die das gewünschte Systemverhalten überprüft. Sollte eine spezifiezierte Anforderung nicht prüfbar sein, so ist dies in meinen Augen auch keine „gültige“ Anforderung.
    Insbesondere bei Geräten im medizinische und Automotive Bereich (sicher auch bei Aerospace + Defense) ist aufgrund der SAFETY-Anforderungen so oder so ein „Whitebox-Test“ im Zielsystem (Steuergerät) als Nachweis der „Code-Coverage“ + „Call-Coverage“ erforderlich und zu dokumentieren, so dass ich hier auch die Zustandsübergänge klar nachvollziehen kann. Hierzu benötigt man natürlich Tools, die dies unterstützen … z.B. Tessy o.ä.
    (Automotive)SPICE schreibt dies ebenso vor, wie die ISO26262 oder ISO62304 … durch die ich auf Ihre WebPage gestoßen bin, da ich mich gerade auch mit medizinischen Geräten bzgl. FDA zertifizierung beschäftige.

    Viele Grüße
    Hartmut Petters

    Interimmanager
    – Leiter SWE Energiespeicher
    – Projektleiter PLM-Einführung Biotec

Kommentar schreiben