{"id":12209,"date":"2025-12-09T08:09:33","date_gmt":"2025-12-09T07:09:33","guid":{"rendered":"https:\/\/medtech-ingenieur.de\/?p=12209"},"modified":"2026-02-17T16:54:56","modified_gmt":"2026-02-17T15:54:56","slug":"sysml-v2-op-leuchten-medizintechnik","status":"publish","type":"post","link":"https:\/\/medtech-ingenieur.de\/en\/sysml-v2-op-leuchten-medizintechnik\/","title":{"rendered":"SysML v2 for operating room lights"},"content":{"rendered":"

Variantenvielfalt und Integrationsdruck: Der unsichtbare Engpass bei OP-Leuchten<\/h2>\n

SysML v2 f\u00fcr OP-Leuchten <\/strong>gewinnt zunehmend an Bedeutung, da OP-Leuchten heute hochkomplexe, mechatronische Medizinger\u00e4te mit steigender Variantenvielfalt darstellen. Mechanik, Optik, Elektronik und Software m\u00fcssen konsistent integriert werden \u2013 gleichzeitig steigen regulatorische Anforderungen und Dokumentationspflichten.<\/p>\n

Gleichzeitig steigt die Variantenvielfalt rasant an: Verschiedene Leuchtengr\u00f6\u00dfen, Farbtemperaturen, Montagearten, Kamera-Systeme, sowie unterschiedliche Steuerger\u00e4te und Kommunikationsanbindungen m\u00fcssen verf\u00fcgbar sein.<\/p>\n

Diese Vielfalt bringt Hersteller an ihre Grenzen. Jede Variante wird separat dokumentiert. Architekturentscheidungen sind kaum nachvollziehbar. Der Aufwand f\u00fcr Traceability und MDR-konforme Dokumentation w\u00e4chst exponentiell an.<\/p>\n

Genau hier setzt das modellbasierte Systems Engineering (MBSE) mit SysML v2 an. Ein neuer Ansatz, der Systemarchitekturen durchg\u00e4ngig modellierbar und Varianten beherrschbar macht. <\/p>\n

\"Probleme<\/span>\"Object<\/a><\/span><\/p>\n

Was ist SysML v2?<\/span><\/strong><\/h3>\n

SysML v2<\/span><\/strong> (Systems Modeling Language Version 2) ist die n\u00e4chste Generation der modellbasierten Systemsprache f\u00fcr komplexe technische Systeme. Sie erm\u00f6glicht es, Systemarchitekturen durchg\u00e4ngig zu modellieren, Varianten effizient zu verwalten und Anforderungen, Tests sowie Designobjekte in einem konsistenten, maschinenlesbaren Rahmen zu verkn\u00fcpfen.<\/span><\/span>Entwickelt wird SysML v2 von der <\/strong><\/span>Object Management Group (OMG)<\/strong><\/span><\/a>, einem internationalen Standardisierungsgremium, das die Sprache gemeinsam mit Industriepartnern und Systemingenieuren weiterentwickelt, um moderne Anforderungen an komplexe, vernetzte Systeme in unterschiedlichen Branchen zu erf\u00fcllen.<\/span><\/p>\n

Von Excel-Listen zu Systemmodellen: Wie SysML v2 Entwicklungsprozesse vereinfacht<\/h2>\n

In vielen Entwicklungsabteilungen beginnt Systems Engineering noch immer mit Excel: Zuerst werden die Anforderungen in Tabellen definiert, die Beschreibung der Schnittstellen und der Architektur findet dann in PowerPoint oder Visio statt. Jeder Fachbereich f\u00fchrt seine eigene Sicht und am Ende wird dann versucht, alles zusammenzubringen. Als Resultat erh\u00e4lt man h\u00e4ufig ein fragiles Geflecht aus Dokumenten: Informationen liegen redundant vor, \u00c4nderungen m\u00fcssen manuell nachgef\u00fchrt werden und kleine Inkonsistenzen k\u00f6nnen sich unbemerkt durch ganze Entwicklungsstufen ziehen.<\/p>\n

Die Folge: Fehleranf\u00e4lligkeit, fehlende oder fehlerhafte Traceability und ein hoher Aufwand, um Zusammenh\u00e4nge zwischen Anforderungen, Architektur und Tests herzustellen und bei \u00c4nderungen zu warten. Gerade in der Medizintechnik, wo regulatorische Nachweise erforderlich sind, f\u00fchrt diese Arbeitsweise schnell an ihre Grenzen.<\/p>\n

SysML v2 macht vieles neu. Statt verstreuter Tabellen und Diagramme entsteht ein integriertes Systemmodell auf Basis eines SysML-v2-Packages, das alle Disziplinen in einem konsistenten, maschinenlesbaren Rahmen verbindet. Dieses Modell wird zum zentralen Anlaufpunkt f\u00fcr die gesamte Entwicklung: Anforderungen, Architektur, Schnittstellen, Verhaltensmodelle und Tests referenzieren auf dieselbe Datenbasis. Durch die textuelle, maschinenlesbare Syntax von SysML v2 lassen sich Modelle versionieren, vergleichen und zusammenf\u00fchren, \u00e4hnlich wie Quellcode in Softwareprojekten.<\/p>\n

\"SysML<\/span><\/p>\n

Praxisbeispiel: Modellierung einer OP-Leuchtenfamilie mit SysML v2<\/h2>\n

Das folgende Beispiel zeigt, wie SysML v2 f\u00fcr OP-Leuchten <\/strong>konkret eingesetzt werden kann, um Varianten systematisch zu modellieren.<\/p>\n

package OperatingLightSystem {<\/p>\n

    \/\/ ————————–<\/p>\n

    \/\/ Value Type Definitions<\/p>\n

    \/\/ ————————–<\/p>\n

    value def Real;<\/p>\n

    value def Lux : Real;<\/p>\n

    value def Kelvin : Real;<\/p>\n

    value def Boolean;<\/p>\n

    enum def ComInterface { RS232; WLAN; Ethernet; }<\/p>\n

    enum def CameraType   { HD4K; HD1080; HD8K; }<\/p>\n

    enum def MountType    { Ceiling; Wall; Mobile; Boom; Rail; }<\/p>\n

    \/\/ ————————–<\/p>\n

    \/\/ Port Definitions<\/p>\n

    \/\/ ————————–<\/p>\n

    port def ControlCommPort {<\/p>\n

        out comInterface : ComInterface;<\/p>\n

        out wireless     : Boolean;<\/p>\n

    }<\/p>\n

    port def CameraConfigPort {<\/p>\n

        out type : CameraType;<\/p>\n

    }<\/p>\n

    port def MountingPort {<\/p>\n

        out mountType : MountType;<\/p>\n

    }<\/p>\n

    port def LightEmissionPort {<\/p>\n

        out intensity        : Lux;<\/p>\n

        out colorTemperature : Kelvin;<\/p>\n

    }<\/p>\n

    \/\/ ————————–<\/p>\n

    \/\/ Part Definitions<\/p>\n

    \/\/ ————————–<\/p>\n

    part def LEDModule {<\/p>\n

        port light : LightEmissionPort;<\/p>\n

    }<\/p>\n

    part def ControlUnit {<\/p>\n

        port comm : ControlCommPort;<\/p>\n

    }<\/p>\n

    part def Camera {<\/p>\n

        port cam : CameraConfigPort;<\/p>\n

    }<\/p>\n

    part def Mounting {<\/p>\n

        port mount : MountingPort;<\/p>\n

    }<\/p>\n

    \/\/ ————————–<\/p>\n

    \/\/ System Definition<\/p>\n

    \/\/ ————————–<\/p>\n

    part def OperatingLightSystem {<\/p>\n

        part led      : LEDModule;<\/p>\n

        part control  : ControlUnit;<\/p>\n

        part camera   : Camera[0..1];<\/p>\n

        part mounting : Mounting;<\/p>\n

        \/\/ System-level default values<\/p>\n

        led.light.intensity        = 16000;<\/p>\n

        led.light.colorTemperature = 3500;<\/p>\n

        control.comm.comInterface = RS232;<\/p>\n

        control.comm.wireless     = false;<\/p>\n

        \/\/ If a camera exists, default is 4K<\/p>\n

        camera.cam.type = HD4K;<\/p>\n

        mounting.mount.mountType = Ceiling;<\/p>\n

    }<\/p>\n

    \/\/ ————————–<\/p>\n

    \/\/ Variant A  (Wall-mounted)<\/p>\n

    \/\/ ————————–<\/p>\n

    part OperatingLight_VariantA : OperatingLightSystem {<\/p>\n

        \/\/ Redefinitions of variant A, e. g.:<\/p>\n

        \/\/ part redefines mounting {<\/p>\n

        \/\/     mount.mountType = Wall;<\/p>\n

        \/\/ }<\/p>\n

    }<\/p>\n

    \/\/ ————————–<\/p>\n

    \/\/ Variant B  (Mobile-mounted)<\/p>\n

    \/\/ ————————–<\/p>\n

    part OperatingLight_VariantB : OperatingLightSystem {<\/p>\n

        \/\/ Redefinitions of variant B, e. g.:<\/p>\n

        \/\/ part redefines mounting {<\/p>\n

        \/\/     mount.mountType = Mobile;<\/p>\n

        \/\/ }<\/p>\n

    }<\/p>\n

}<\/p>\n

\"\"<\/span><\/p>\n

Dieses Modell erzeugt automatisch verschiedene Konfigurationen. Eine Variante A, mit Kamera und Wireless-Modul und auch eine Variante B, ohne Kamera und mit Verkabelung anstelle eines Wireless-Moduls.<\/p>\n

Traceability und Zulassung mit SysML v2 f\u00fcr OP-Leuchten <\/strong>automatisch sichern<\/h2>\n

Unser SysML v2-Modell kann nun Anforderungen, Risiken und Test-Cases direkt referenzieren:<\/p>\n

requirement def LightIntensityRequirement <\/span><\/p>\n

{ <\/span><\/p>\n

        attribute intensityMeasured :> ISQ::illuminance;   <\/span><\/p>\n

        id = „REQ-001“; <\/span><\/p>\n

        text = „The illumination intensity shall not exceed 160 000 Lux.“;<\/span><\/p>\n

         require constraint <\/span><\/p>\n

        {     <\/span><\/p>\n

                intensityMeasured <= 160000 [SI::lx] <\/span><\/p>\n

        } <\/span><\/p>\n

}   <\/span><\/p>\n

testcase VerifyLightIntensity satisfies LightIntensityRequirement;<\/span><\/p>\n

Damit kann man eine konforme Traceability zwischen Anforderung \u21fe Design \u21fe Test automatisch erf\u00fcllen. \u00c4ndert sich im Nachhinein eine Anforderung, werden alle betroffenen Items (z. B. im Design) markiert.<\/p>\n

Warum SysML v2 f\u00fcr OP-Leuchten <\/strong>bei komplexen OP-Leuchten entscheidend ist<\/h2>\n\n\n\n\n\n\n\n
\n

Herausforderung<\/strong><\/p>\n<\/th>\n

\n

Nutzen durch SysML v2<\/strong><\/p>\n<\/th>\n<\/tr>\n<\/thead>\n

\n

Viele Varianten und Optionen<\/p>\n<\/td>\n

<\/p>\n

Parametrisierte Architektur, automatisierte Generierung<\/p>\n<\/td>\n<\/tr>\n

\n

Kombination aus Mechanik, Elektronik, Software<\/p>\n<\/td>\n

<\/p>\n

Durchg\u00e4ngiges Systemmodell statt Einzeldokumente<\/p>\n<\/td>\n<\/tr>\n

\n

MDR-Nachweispflicht<\/p>\n<\/td>\n

<\/p>\n

Integrierte Traceability und \u00c4nderungsdokumentation<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Besonders interessant wird es, wenn SysML v2-Modelle durch dom\u00e4nenspezifische Sprachen (DSLs) erg\u00e4nzt werden.Daraus lassen sich automatisch SysML v2-Modelle, Konfigurationsdateien und sogar Firmware-Parameter ableiten.<\/p>\n

\"SysML<\/span><\/p>\n

Fazit: Vom Leuchtenhersteller zum Systemintegrator mit SysML v2<\/h2>\n

SysML v2 f\u00fcr OP-Leuchten <\/strong>erm\u00f6glicht es, OP-Leuchten nicht mehr als Einzelprodukte, sondern als systemisch modellierte Produktfamilien zu verstehen.<\/p>\n

 Hersteller k\u00f6nnen so:<\/p>\n