Was ist ein System? Was zunächst nach einer einfachen Frage klingt, kann es mitunter in sich haben. Denn die Frage ist nicht eindeutig zu beantworten. Die Antwort hängt von der Sichtweise und dem Entwicklungskontext ab. Doch warum soll man sich die Frage überhaupt stellen? Systeme werden in der heutigen Zeit immer komplexer und wechselwirken mit anderen Systemen. Um die sich daraus ergebende Komplexität beherrschbar zu machen, hilft der Ansatz „teile und herrsche“. Es werden somit Systeme in Subsysteme zerlegt.
Ein System ist somit eine rekursive Struktur und besteht wiederum aus Systemen. Das Ganze wird oft mit dem Schlagwort „System-of-Systems“ bezeichnet.
In diesem Blog-Artikel möchte ich auf die Definition, was ein System ist, eingehen und vorstellen wie man ein Systemkontext-Diagramm erstellt, die Systemgrenze festlegt und damit eine klare Antwort auf die Frage „was ist mein System?“ findet.
Definition des Begriffs System
Beginnen wir zunächst einmal mit der Begriffsklärung „System“. Dazu gibt es verschiedene Quellen, die mehr oder weniger ähnliche Definitionen vom Begriff System liefern.
| Quelle | Definition |
| INCOSE Systems-Engineering Handbuch V.3.2.2-de (International Council on Systems Engineering) |
Eine Gruppe von interagierenden Elementen, die so organisiert sind, dass sie eine oder mehrere vorgegebene Aufgaben erfüllen. |
| Wikipedia | Als System (altgr. σύστεμα sýstēma, „aus mehreren Einzelteilen zusammengesetztes Ganzes“) wird allgemein eine Gesamtheit von Elementen bezeichnet, die so aufeinander bezogen oder miteinander verbunden sind und in einer Weise interagieren, dass sie als eine aufgaben-, sinn- oder zweckgebundene Einheit angesehen werden können, als strukturierte systematische Ganzheit. In unterschiedlichen Fachgebieten werden darüber hinaus spezifischere Begriffsverwendungen vorgeschlagen, diskutiert und angewendet. |
| ISO26262 | Menge von Elementen (Systemelementen), mindestens Sensoren, Verarbeitungseinheiten und Aktuatoren, die gemäß einem Entwurf in einer Beziehung zueinander stehen. Anmerkung: Ein Systemelement kann auch selbst wieder ein System sein. |
Nach der DIN EN 60601-1 ergeben sich die folgenden System-Definitionen für die Medizintechnik.
| Medizinisches elektrisches System (ME-System) | Kombination von einzelnen Geräten, wie vom Hersteller festgelegt, von denen mindestens eines ein ME-Gerät sein muss und die durch eine Funktionsverbindung oder durch den Gebrauch einer Mehrfachsteckdose zusammengeschlossen sind. |
| Programmierbares elektrisches medizinisches System (PEMS) | ME-Gerät oder ME-System, das ein oder mehrere programmierbare elektronische Subsysteme (PESS) enthält. |
| Programmierbares elektronisches Subsystem (PESS) | System, das auf einer oder mehreren zentralen Prozessoreinheiten beruht, einschließlich deren Software und Schnittstellen. |
|
|
| Dipl.-Ing. Goran Madzar, Gesellschafter, Senior Systems Engineer E-Mail: madzar@medtech-ingenieur.de Tel.: +49 9131 691 240 |
|
Benötigen Sie Unterstützung bei der Entwicklung Ihres Medizingeräts? Wir helfen gerne! Die MEDtech Ingenieur GmbH bietet Hardware-Entwicklung, Software-Entwicklung, Systems Engineering, Mechanik-Entwicklung und Beratung aus einer Hand. Nehmen Sie Kontakt mit uns auf. |
|
Überblick verschaffen durch Systemkontext
Als Systemarchitekt ist es eine meiner ersten Aufgaben den Systemkontext zu modellieren. Dazu erstelle ich ein Diagramm mit allen beteiligten Systemen und Personen. An dieser Stelle gehe ich unter Umständen weit über meinen Verantwortungsbereich hinaus. Selbst wenn ich nur für eine Komponente des Systems verantwortlich bin, benötige ich dennoch den Systemkontext. Denn nur wenn ich alle beteiligten Systeme kenne, kann ich klar trennen, welches System ich im Weiteren betrachten werde und welches nicht. Zudem findet man durch den Systemkontext wichtige Schnittstellen zu den anderen Systemen, die zu beachten sind. Meine Empfehlung ist es daher für jedes System einen Gesamtüberblick als Systemkontext aufzuzeichnen. Anschließend führe ich eine Systemabgrenzung durch. Das bedeutet, dass ich im weiteren Verlauf nur für einen Teil des Gesamtsystems die Verantwortung übernehme. Sämtliche Spezifikationen und Entwicklungsergebnisse werden für die Teile erstellt, die innerhalb der Systemgrenze liegen. Die Systemgrenze klärt für mich somit die Frage: „Was ist drin und was ist draußen?“. Diese Frage ist sehr wichtig und hilfreich. Denn dann kann ich im nächsten Schritt die Schnittstellen an der Systemgrenze definieren. Z. B. kann ein System eine Netzversorgung als Eingang haben. Es ist klar, dass das Gerät kein Kraftwerk beinhaltet. Daher ist die Netzversorgung draußen und die Stromversorgung bildet die Schnittstelle des Systems. Es kann auch sein, dass das Gerät Daten an ein Kliniknetzwerk übermittelt. Auch das möchte ich nicht innerhalb meines Systems haben. Daher bildet die Datenschnittstelle zum Kliniknetzwerk die Schnittstelle meines Systems. Da Fehler beim Design von Systemen meistens an Systemgrenzen geschehen, ist es wichtig, die Schnittstellen genau zu spezifizieren.
Systemabgrenzung durchführen
Wie wir bereits gesehen haben, ist die Festlegung der Systemgrenze nicht fest vorgegeben. Woran soll man dann festmachen, wo die Systemgrenze zu verlaufen hat? Um diese Frage zu klären, habe ich ein paar Anhaltspunkte formuliert, die bei der Abgrenzung helfen können.
Welche Systeme können unabhängig voneinander betrieben werden?
Kann ein System unabhängig von einem anderen betrieben werden, dann sollten die beiden Systeme getrennt voneinander betrachtet werden.
Minimierung der Schnittstellen
Bei der Festlegung der Systemgrenze ist darauf zu achten, die Schnittstellen an der Systemgrenze möglichst gering zu halten. Dadurch reduziert man die Komplexität und den Testaufwand auf Systemebene.
Für welches Teilsystem oder System übernehme ich die Verantwortung?
Das ist eine zentrale Frage. Mit der Systemgrenze legt man auch seinen Verantwortungsbereich fest. Daher sollte man nicht Teile einbeziehen, für die man die Verantwortung nicht übernehmen kann oder will. Das ist häufig bei Auftragsentwicklungen der Fall. Ein Lieferant oder die Entwicklungsabteilung kann nur für das selbst entwickelte System die Verantwortung übernehmen. Umso wichtiger ist es, den Verantwortungsbereich klar zu kennzeichnen und den anderen Stakeholdern im Projekt klar die Verantwortlichkeit zu kommunizieren.
Was soll gemeinsam und was getrennt zugelassen werden?
Stellen Sie sich die Frage, welche Teile einzeln und welche Sie als System zulassen möchten. Teile die getrennt zugelassen werden, können auch getrennt modelliert werden.
Zeitliche Abfolge in der Entwicklung
Wenn ein Teilsystem bereits existiert und das andere erst entwickelt werden soll, dann spricht das dafür die Teilsysteme getrennt zu betrachten. Gleiches gilt auch dafür, wenn die Entwicklung nicht gleichzeitig stattfinden soll.
Modellierung mit einem SysML-Werkzeug
Dazu verwende ich Enterprise Architect und modelliere den Systemkontext in SysML. Sie können den Systemkontext aber auch an einem Whiteboard, Flipchart oder mit Power Point zeichnen. Das Werkzeug ist dabei nicht so wichtig. In der Abbildung unten sehen Sie den Systemkontext für ein sehr einfaches System.
Und wie verifiziert man das ganze nun?
Das ist eine sehr gute Frage. Schließlich hat man ein System in verschiedene Teilsysteme zerlegt und diese einzeln spezifiziert und verifiziert. Selbstverständlich muss man ebenfalls das Gesamtsystem verifizieren und validieren. Die Basis dafür können die Marketing Requirements oder die Gesamtsystem-Spezifikation bilden. Damit soll man in der Lage sein, das Gesamtsystem bestehend aus den verschiedenen Teilsystemen, als Ganzes zu betrachten und die Anforderungen daran zu prüfen.
Mein Tipp:
Erstellen Sie ein Diagramm mit dem Systemkontext Ihres Systems und sprechen Sie mit Ihren Kollegen darüber. Sie werden von „So habe ich das System noch nie gesehen“ bis „Aber gehört dies und das nicht auch zum System“ einiges an Feedback bekommen. Und das ist auch gut so. Sprechen Sie sich ab und definieren Sie gemeinsam die Systemgrenze.
Wenn Sie Unterstützung bei der Erstellung eines Systemkontext-Diagramms benötigen oder aber innerhalb eines Workshops die Systemgrenze festlegen möchten, sprechen Sie mich bitte an. Gerne helfe ich Ihnen dabei Klarheit über Ihr System zu erlangen.
Mehr Informationen zu medizinischen elektrischen Systemen finden Sie auch im Podcast von Stefan Bolleininger in der Episode 9 medizinisch elektrische Systeme.
Ich freue mich über Feedback und wenn Sie mit mir in Kontakt treten. Sie können gerne auch einen Kommentar zu dem Artikel abgeben. Falls Sie jemanden kennen, für den der Blog ebenfalls interessant sein könnte, freue ich mich auch sehr über eine Weiterempfehlung.
Viele Grüße
Goran Madzar