Variety of options and pressure to integrate: The invisible bottleneck in operating room lights
SysML v2 for operating room lights Operating room lights are becoming increasingly important, as they are now highly complex, mechatronic medical devices with a growing variety of models. Mechanics, optics, electronics, and software must be consistently integrated – while regulatory requirements and documentation obligations are also increasing.
At the same time, the variety of options is increasing rapidly: different luminaire sizes, color temperatures, mounting types, camera systems, as well as different control units and communication connections must be available.
This diversity pushes manufacturers to their limits. Each variant is documented separately. Architectural decisions are barely comprehensible. The effort required for traceability and MDR-compliant documentation increases exponentially.
This is precisely where model-based systems engineering (MBSE) with SysML v2 comes in. It's a new approach that makes system architectures consistently modelable and variants manageable.
What is SysML v2?
From Excel spreadsheets to system models: How SysML v2 simplifies development processes
In many development departments, systems engineering still begins with Excel: First, the requirements are defined in spreadsheets, then the interfaces and architecture are described in PowerPoint or Visio. Each department maintains its own perspective, and finally, an attempt is made to bring everything together. The result is often a fragile web of documents: Information is redundant, changes have to be manually tracked, and minor inconsistencies can creep unnoticed through entire development phases.
The result: susceptibility to errors, missing or faulty traceability, and a high effort required to establish connections between requirements, architecture, and tests, and to maintain these connections after changes. Especially in medical technology, where regulatory compliance is required, this approach quickly reaches its limits.
SysML v2 brings many changes. Instead of scattered tables and diagrams, an integrated system model is created based on a SysML v2 package, connecting all disciplines within a consistent, machine-readable framework. This model becomes the central point of contact for the entire development process: requirements, architecture, interfaces, behavioral models, and tests all reference the same data. Thanks to the textual, machine-readable syntax of SysML v2, models can be versioned, compared, and merged, much like source code in software projects.
Practical example: Modeling a family of operating room lights with SysML v2
The following example shows how SysML v2 for operating room lights It can be used specifically to systematically model variants.
package OperatingLightSystem {
// --------------------------
// Value Type Definitions
// --------------------------
value def Real;
value def Lux : Real;
value def Kelvin : Real;
value def Boolean;
enum def ComInterface { RS232; WiFi; Ethernet; }
enum def CameraType { HD4K; HD1080; HD8K; }
enum def MountType { Ceiling; Wall; Mobile; Boom; rails; }
// --------------------------
// Port Definitions
// --------------------------
port def ControlCommPort {
out comInterface : ComInterface;
out wireless : Boolean;
}
port def CameraConfigPort {
out type : CameraType;
}
port def MountingPort {
out mountType : MountType;
}
port def LightEmissionPort {
output intensity: Lux;
out colorTemperature : Kelvin;
}
// --------------------------
// Part Definitions
// --------------------------
part def LEDModule {
port light : LightEmissionPort;
}
part def ControlUnit {
port comm : ControlCommPort;
}
part def Camera {
port cam : CameraConfigPort;
}
part def Mounting {
port mount : MountingPort;
}
// --------------------------
// System Definition
// --------------------------
part def OperatingLightSystem {
part led : LED module;
part control : ControlUnit;
part camera : Camera[0..1];
part mounting : Mounting;
// System level default values
led.light.intensity = 16000;
led.light.colorTemperature = 3500;
control.comm.comInterface = RS232;
control.comm.wireless = false;
// If a camera exists, default is 4K
camera.cam.type = HD4K;
mounting.mount.mountType = Ceiling;
}
// --------------------------
// Variant A (Wall-mounted)
// --------------------------
part OperatingLight_VariantA : OperatingLightSystem {
// Redefinitions of variant A, eg:
// part redefines mounting {
// mount.mountType = Wall;
// }
}
// --------------------------
// Variant B (mobile mounted)
// --------------------------
part OperatingLight_VariantB : OperatingLightSystem {
// Redefinitions of variant B, eg:
// part redefines mounting {
// mount.mountType = Mobile;
// }
}
}
This model automatically generates different configurations. One variant A, with a camera and wireless module, and also a variant B, without a camera and with cabling instead of a wireless module.
Traceability and approval SysML v2 for operating room lights automatically back up
Our SysML v2 model can now directly reference requirements, risks, and test cases:
requirement def LightIntensityRequirement
{
attribute intensityMeasured :> ISQ::illuminance;
id = "REQ-001";
text = "The illumination intensity shall not exceed 160 000 Lux.";
require constraint
{
intensityMeasured <= 160000 [SI::lx]
}
}
testcase VerifyLightIntensity satisfies LightIntensityRequirement;
This allows for automatic compliance with traceability between requirements → design → testing. If a requirement changes subsequently, all affected items (e.g., in the design) are flagged.
Why SysML v2 for operating room lights is crucial for complex operating room lights
Challenge | Benefits of SysML v2 |
|---|---|
Many variants and options | Parameterized architecture, automated generation |
Combination of mechanics, electronics, software | A consistent system model instead of individual documents |
MDR compliance requirement | Integrated traceability and change documentation |
Things get particularly interesting when SysML v2 models are supplemented by domain-specific languages (DSLs).
SysML v2 models, configuration files and even firmware parameters can be automatically derived from this.
Conclusion: From lighting manufacturer to system integrator with SysML v2
SysML v2 for operating room lights This makes it possible to understand operating room lights not as individual products, but as systemically modeled product families.
Manufacturers can thus:
- Manage variants efficiently,
- Reduce the approval process,
- and consider the model as the central, consistent basis.
For engineering teams, this means: less redundancy, more traceability, more automation.
At MEDtech Ingenieur, we also regularly host events in cooperation with the VDI (Association of German Engineers) on the topic of SysML v2, in order to remain at the forefront of systems engineering and actively shape its development. Last year, for example, we were able to... Lecture by Tim Weilkiens (Co-developer at OMG and trainer at OOSE) and a Lecture with Hendrik Dahmke offer.
Would you like to know how SysML v2 can be used specifically in medical technology development?
We would be happy to show you, using your product as an example, how a model-based development project could look for you. Send us a no-obligation initial inquiry and we will be happy to assist you.