Software in Medizinprodukten - medconf.de · ☺Open source IDE (Eclipse bundle, osate.org) ist...

qtec group qtec consult | qtec services | qtec academy

SOFTWARE IN MEDIZINPRODUKTEN

qtec group GmbH

Torsten Hertz

21.11.2018 1

Per Modell von der Architektur zum Detaillierten Design

• Studium ET / Techn. Informatik an der TUHH

• >24 Jahre Medizintechnik

• Produktgruppen: Beatmung, Wärmetherapie, Monitoring, Medical Imaging (MRT)

• Fachthemen:

• Requirements Management,Systems Engineering, Software Engineering,Project Management,Quality Assurance,Medical Product Development

VORSTELLUNGDipl.-Ing. Torsten Hertz

qtec group qtec consult | qtec services | qtec academy21.11.20182

• Vorstellung / Agenda

• Was fordert die IEC 62304?

• Modellierung als Konzept

• Architektur – Views und Beispiele

• Detailliertes Design – Views und Beispiele

• Frameworks, Notationen und Werkzeuge

• Fazit

• Quellen

qtec group qtec consult | qtec services | qtec academy21.11.2018 3


WAS FORDERT DIE IEC 62304……in der hier betrachteten Edition 1.1?

21.11.2018 4

Ein Auszug:

• ARCHITEKTUR

• MEDICAL DEVICE SOFTWARE

• RISK CONTROL

• SOFTWARE ITEM

• SOFTWARE PRODUCT

• SOFTWARE SYSTEM

• SOFTWARE UNIT

• SOUP (SOFTWARE OF UNKNOWN PROVENANCE)

• TRACEABILITY

• VERIFICATION

IEC 62304 V1.1 -DEFINITIONENAbschnitt 3: Terms and Definitions (nach [1],[2])


• Die Software (SW) Requirements sollen in eine dokumentierte Architektur abgebildet werden; dabei soll die Struktur der SW dargestellt und die daran beteiligten SW-Komponenten (SW Items) identifiziert werden.

• Es sollen die Schnittstellen zwischen den identifizierten SW-Komponenten (intern) aber auch die Schnittstellen zwischen den Komponenten und externen Komponenten dokumentiert werden (für die Fachbereiche SW als auch Hardware (HW)).

• Wird eine SW-Komponente als Software of Unknown Provenance (SOUP) identifiziert, so sollen für diese (funktionale und nichtfunktionale) Anforderungen erhoben werden, die im Rahmen einer Zweckbestimmung erfüllt sein müssen. Weiterhin soll die Systemumgebung (SW und HW) festgelegt sein, in welcher die SOUP eingebettet werden soll.

• Risikomindernde Maßnahmen müssen im Zuge der Auftrennung (Segregation) der SW-Komponenten berücksichtigt, hervorgehoben und erklärt werden, [C].

• Die Architektur soll prüfbar sein hinsichtlich ihrer Traceability zu den Anforderungen, ihrer (internen und externen) Schnittstellen und der Integration von SOUP-Komponenten.

IEC 62304 -ANFORDERUNGENAbschnitt 5.3: Software Architectural Design [Klassen B,C] (nach [1],[2],[5])


• Die Software (also deren in der Architektur enthaltenen Komponenten) soll weiter unterteilt werden bis SW-Einheiten (SW Units) vorliegen, die nicht weiter teilbar sind.

• Das Design jeder SW-Einheit soll so detailliert beschrieben sein, dass die korrekte Implementierung der Einheit gegeben ist [C].

• Das Design jeder Schnittstelle (intern und extern) soll so detailliertbeschrieben sein, dass die korrekte Implementierung der Schnittstelle gegeben ist [C].

• Es soll geprüft werden, dass das detaillierte Design (Output) die SW-Architektur (Input) widerspruchsfrei implementiert (unter Zuhilfenameder Traceability zur Architektur) [C].

IEC 62304 -ANFORDERUNGENAbschnitt 5.4: Software Detailed Design [Klassen B,C] (nach [1],[2],[5])



MODELLIERUNG ALS KONZEPT

21.11.2018 8

• Definition Ontologie…[8]…ist eine formal geordnete Darstellung einer Menge von Begrifflichkeiten und der zwischen ihren bestehenden Beziehungen in einem bestimmten Gegenstandsbereich [6].

• Wir benutzen Ontologien z.B. in den Bereichen:

• Sammlung und Darstellung von Wissen

• Schulung und Austausch von Expertenwissen

• Anforderungsmanagement und Systems-Engineering

• Übergang vom (klassifizierendem) Begriff zur (realen) Instanz führt zur Erklärung des Schemas Klasse → Objekt in der objektorientierten SW-Entwicklung.

• Ontologie (vs. Taxonomie) ist ein mächtig(er)es Schema, da neben einer geordneten Struktur (z.B. Containment Tree bestehend aus Elementen → Taxonomie) auch auf die Beziehung zwischen den Elementen eingegangen wird.

• Ontologien können konkret als Modell bearbeitet und abgespeichert werden.

MODELLIERUNG ALS KONZEPToder: Wie setze ich Ontologien als Startpunkt für eine Software-Architektur ein?


• Das Modell ist ein multidimensionales Konstrukt, welches neben den Kernbestandteilen, Knoten und Assoziationen, auch eine Menge von semantischen Zusätzen wie Typen, Stereotype, Attribute, Auszeichnungen (Tags) und vor allem eine (möglichst vorab) vereinbarte Menge an Regeln zur Notation mitbringt.

• Zur Darstellung unterschiedlicher Modell-Facetten benutzt man Sichten (Views).

• Weitere Metaphern zur Veranschaulichung des Prinzips (nach [7]):

• Standpunkt (Perspective)

• Blickwinkel (Viewpoint)

• Für die Modellierung von Software hat sich seit geraumer Zeit die UML (Unified Modeling Language) als de-facto Standard für die Notation und Nomenklatur durchgesetzt.

• Beispiel: Die UML bietet unterschiedliche Diagrammtypen an; ein Diagramm erhält man per eingenommener Perspective und gewähltem Viewpoint, wenn man das Modellentlang einer View auf die Diagrammfläche projiziert.

MODELLIERUNG ALS KONZEPTEin Modell und viele Sichten…



ARCHITEKTUR

21.11.2018 11

ARCHITEKTUR META-MODELLBegriffe im Zusammenhang – IEEE 1471:2000 / IEEE 42010 (aus [6])


• Die Software Anforderungen (Design Input) [5] treiben die Entwicklung der Software Architektur an:

• Funktionale Anforderungen:

• Die funktionalen Anforderungen bringen die Architektur-Elemente namentlich ins Spiel.

• Hier wird auch die grundsätzliche Art der Interaktion spezifiziert (ohne auf das dynamische Verhalten im Detail einzugehen).

• → Der Entwurf einer logisch-funktionalen Grobarchitektur liefert die initiale Architektur

• Nicht-funktionale Anforderungen:

• Die Spezifikation von Anforderungen, die Qualitätsattribute und Performance festlegen, haben einen großen Einfluss auf die Aufteilung der Elemente, der Schnittlinie bei deren Zerlegung und vor allem auf die Schnittstellen. Häufig auftretende Attribute:

• Skalierbarkeit und Mengengerüste• Volumina und Raten (Datenmengen, Flussraten, Bandbreiten, Ereignis-Häufigkeiten)• Latenzen

ARCHITEKTUR-QUELLENFunktionale und nicht-funktionale Software Anforderungen



ANWENDBARE DIAGRAMME

21.11.2018 14

ANWENDBARE DIAGRAMMEAuswahl aus der UML – gegliedert nach Aspekt und Detaillierung ([3],[4])


Struktur Verhalten

Architektur (grob)• Paketdiagramm• Komponentendiagramm

• Anwendungsfalldiagramm

Architektur (fein)Design (detailliert)

• Paketdiagramm• Klassendiagramm• Kompositionsstrukturdiagramm• Verteilungsdiagramm

• Aktivitätsdiagramm• Zustandsdiagramm• Sequenzdiagramm• Zeitverlaufsdiagramm• Kommunikationsdiagramm• Interaktionsübersichtsdiagramm

• Praktisches Beispiel: Finger-Puls-Oximeter (FPO)

• Messung und Anzeige der Blutsauerstoffsättigung (SpO2 [%])

• Messung und Anzeige der Pulsrate (PR [bpm])

• Visualisierung des Plethysmogramms (PLETH [-]) pulox.de

• Zweck

• Fasst ausgewählte Architekturelementezu logischen Paketen zusammen.

• Verschachtelte Darstellung (Containment)möglich

• Definiert (qualifizierte) Namensräume (:: Notation)

• Darstellung

• Container-Symbolik, Assoziationen

• Elemente

• SW Komponenten (grob) / Unterpakete

• Verwendung

• Inhaltsverzeichnis einer Architekturebene

• Zusammenfassung Bibliotheken

• Unterscheidung eigenes Design / SOUP

SICHT: STRUKTUR (GROB)Das Paketdiagramm


• Zweck

• Stellt die Schnittstellen und Verbindungen vonKomponenten dar (Blackbox)

• Darstellung

• Schnittstellen als Ports, Verbindungen direkt oderin Ball-Socket (oder Lolly) -Notation

• Elemente

• SW Komponenten, Konnektoren

• Richtungssinn: Ball: provide, Socket: require

• Verwendung

• Dekomposition / Segregation („Schnittlinie“)

• Qualitätsziele:

• Vermeidung unnötiger Komplexität

• Wiederverwendbarkeit / Wartbarkeit

SICHT: STRUKTUR (GROB)Das Komponentendiagramm



DETAILLIERTES DESIGN

21.11.2018 18

SICHT: STRUKTUR (FEIN)Das Paketdiagramm


• Zweck

• Stellt die betrachteten Architekturelemente dar und fasst diesezu logischen Paketen zusammen.

• Verschachtelte Darstellung (Containment)möglich

• Definiert Namensräume (:: Notation)

• Darstellung

• Container-Symbolik, Assoziationen

• Elemente

• SW Komponenten, Units (fein), Klassen / Unterpakete

• Verwendung

• Darstellung der Feinarchitektur → Klasse C

• Generell: Die Innenstruktur einer Unit ist nach außennicht sichtbar!

• Zweck

• Stellt die Klassen und deren Assoziationen untereinander dar(Whitebox)

• Darstellung

• Klassen als Blöcke mit Member-Attribute und -Methoden

• Elemente

• Klassen

• Assoziationen (inkl. Kardinalitäten)

• Attribute und Methoden: Member verkörpern Schnittstellen

• Verwendung

• Ausdrucksform des gewählten Entwurfsmusters

• Detaillierter Bauplan des statischen SW-Designs

• Hauptvorgabe für die anschließende Implementierung

SICHT: STRUKTUR (FEIN)Das Klassendiagramm


• Zweck

• Abläufe von Aktivitäten visualisieren, Quelle: Use Cases

• Darstellung

• Ähnlichkeit zum klassischen Flussdiagramm, BPMN

• Elemente

• Aktivitätsbereich (Gruppierung in Organisationseinheiten)

• Aktionen (atomar) / Ereignisse / Signale

• Kontrollflüsse als gerichtete, attributierte Kanten

• Entscheidungen (decision) / Verbindungen (merge), pre-/post-conditions

• Gabelung (fork) / Vereinigung (joint) / Schleifen

• Verwendung

• Beschreibung von Abläufen, auch Nebenläufigkeiten

• Darstellung von Synchronisationen, Behandlung von Ausnahmen

• Erstellung von (Laufzeit-)Testfällen

SICHT: VERHALTENDas Aktivitätsdiagramm


• Zweck

• Zustände und Übergänge im Zusammenhang mit Ereignissen und Aktionen darstellen

• Darstellung

• Zustände als Knoten, Transitionen als Kanten

• Elemente

• Startzustand Z0 und Folgezustände Z1..n

Endzustand Zn+1 (optional)

• Ereignisse und Transitionen (deren Attribute)Syntax: Event [Guard] / Aktion

• Verwendung

• Beschreibung von Systemreaktionen als endlichen Automaten (z.B. Moore, Mealy), verschachtelte Automaten (Harel)

• Spezifikation und Implementierung von Protokollen

SICHT: VERHALTENDas Zustandsdiagramm


• Zweck

• Darstellung von Nachrichtenflüssen innerhalb eines Szenarios

• Darstellung

• Lebenslinien (swimlanes) mit vertikaler Zeitachse

• Elemente

• Dynamik von Part / Property verkörpert als Lebenslinie

• Zeitabschnitt als Ausführungsbalken (aktiv)

• (Synchrone) Nachrichten zwischen den Swimlanes

• Verwendung

• Darstellung von Synchronisationen zur Laufzeit

• Visualisierung von Kommunikationsabläufen und Interaktionen

SICHT: VERHALTENDas Sequenzdiagramm



FRAMEWORKS, WEITERE NOTATIONEN UND WERKZEUGE

21.11.2018 24

• Prozess, Struktur und Schablonen zur Erstellung einer SW-Architektur am Beispiel von arc42:

• Methode: Aufgabe, Lösung, Bewertung, siehe rechts, ([6])

• Metapher: 12 Schubladen, die inhaltlich zu befüllen sind.

• Sehr praxisbezogenes Framework, arc42 ist „open source“!



• Erweiterte Notation basierend auf der UML: SysML (System Modeling Language)

• Favorisierte Notation der Systemarchitekten und -ingenieure

• Anwendbar auch für die Fachbereiche Elektronik und Mechanik (UML: fokussiert stark auf Software, OOP)

• Wesentliche Merkmale vs. UML:

• Neu: Anforderungsdiagram, Zusicherungsdiagramm

• Geändert:

• Klasse → Block

• Objekt → Property, Ports

• Klassendiagramm → Blockdefinitionsdiagramm

• Kompositionsstrukturdiagramm → Internes Blockdiagramm

• Verteilungsdiagramm → Allokationsdiagramm



aus [8]

• Nicht-grafische(!) Architekturspezifikation mit AADL (Architecture Analysis & Design Language), publiziert und gepflegt von der SAE, Carnegie Mellon University ([9]).

☺ Syntaktisch-präzisere Spezifikation anstatt des „Zeichnens“ von Architektur → keine Mehrdeutigkeiten bei Verwendung von Modellelementen, keine Tool-Abhängigkeiten

☺ Open source IDE (Eclipse bundle, osate.org) ist verfügbar

☺ Formale Verifikation der Architektur ist ein natürlicher Bestandteil der AADL

Mächtige & umfangreiche DSL, erhöhter Aufwand beim Erlernen



http://osate.org/

• Anwendung modellbasierter SW-Spezifikation ist in jedem Fall lohnenswert:

• Durchgängigkeit der Spezifikation und der Toolchain

• Risiko der Fehlinterpretation geringer

• Modell ist besser pflegbar

• Wiederverwendbarkeit vorteilhaft

• Modell und Views als zentraler Bestandteil der Produktdokumentation (DHF):

• Der Hersteller legt die Information per View fest - auch was nicht sichtbar sein muss/darf!(angepasst an den jeweiligen Darstellungszweck / Stakeholder)

• Benannte Stellen propagieren mittlerweile die modellgetriebene Darstellung in Diagrammform

• Ganz ohne niedergeschriebene Prosa geht es allerdings auch nicht:

• Festlegung der Methoden und Materialien im SW-Entwicklungsplan

• Anlegen eines „Rahmendokuments“ (SAD), welche die Views aggregiert

ZUSAMMENFASSUNG UND FAZITPer Modell von der Architektur zum Detaillierten Design


[1] IEC 62304 AMD 1:2015-06: Medizingeräte-Software - Software-Lebenszyklus-Prozesse, Beuth

Verlag, 2015

[2] C.Johner, M.Hölzer-Klüpfel, S Wittorf: Basiswissen Medizinische Software, dpunkt.verlag,

2015

[3] T.Weilkiens: Systems Engineering mit SysML/UML, dpunkt.verlag, 2014

[4] C.Kecher, A.Salvanos: UML 2.5 – Das umfassende Handbuch (5.Aufl.), Rheinwerk Computing,

2015

[5] Johner Institut: Software & IEC 62304, diverse Fachartikel im Web Blog unter:

www.johner-institut.de/blog/category/iec-62304-medizinische-software

[6] S.Zörner: Softwarearchitekturen dokumentieren und kommunizieren,

Hanser Verlag, 2015

[7] N.Rozanski, E.Woods: Software Systems Architecture: Working with Stakeholders Using

Viewpoints and Perspectives, Pearson Education, 2011

[8] Wikipedia (EN,DE)

[9] P.H.Feiler, D.P. Gluch: Model-Based Engineering with AADL, Pearson Education, 2012


QUELLEN UND REFERENZEN

Vielen Dank für Ihr Interesse!

Haben Sie Fragen?


Software in Medizinprodukten - medconf.de · ☺Open source IDE (Eclipse bundle, osate.org) ist...

Documents

Transcript of Software in Medizinprodukten - medconf.de · ☺Open source IDE (Eclipse bundle, osate.org) ist...