Variety of options and pressure to integrate: The invisible bottleneck in operating room lights
Operating lights may appear unassuming at first glance, but they are technologically highly complex medical devices. They combine various engineering disciplines such as mechanics, optics, electronics, and software, and are increasingly being supplemented with digital interfaces for telemedicine or operating room integration.
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.
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 simplified example is intended to show how a family of LED lights could be represented in SysML v2:
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.
Automatically ensure traceability and approval with SysML v2
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 is crucial, especially 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
With SysML v2, the operating light is no longer conceived as a standalone product, but as part of a configurator.
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.
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.