operator safety input is where all operator safety devices get wired. that includes doors, light curtains etc.
detail depend on cell design and application. since more than one device need to be connected, additional circuitry is needed.
note that simply connecting contacts of several safety devices in series is possible but there are issues with this. one is that this limits achievable safety category (check your country standards). also all devices would need dry contact outputs. when this is not the case, that device would need own monitoring relay. some light curtains have EDM which allows one to simply use of pair of safety relays instead of a self monitoring light curtain relay.
we use safety PLC to make the wiring simpler, allow us to create logic and far better troubleshooting (if you ever attempted to trace problem while following bunch of wires in redundant safety circuit, you would know what i mean).
as far as i can tell, your light curtain does not have EDM so you would need monitoring relay or safety plc.
OSSDs act like "dry contacts" on a relay. For a KRC, the X11 sources a safety signal on the Test outputs, and needs to see that signal return on specific safety inputs. And every safety input is dual-channel, A and B.
To satisfy Operator Safety, one of the Test-A outputs needs to be connected directly to Operator Safety A, and one of the Test-B outputs needs to be connected directly to Operator Safety B.
So, connecting Test-A and OS-A to the OSSD-A, and ditto for the B channel, would let you connect one light screen:
X11.TestA->LS1.OSSD.A.1
X11.OpSafeA<-LS1.OSSD.A.2
(repeat for Bs)
When the LS is unbroken, it will connect OSSD.A.1 to OSSD.A.2, and ditto for the Bs. To the X11, it would be the same as if someone had simply wired the Test outputs directly to the safety inputs.
The issue, as Panic says, is combining multiple light screens. You cannot wire them in parallel. Sometimes they're designed so you can simply wire them in series, so:
X11.TestA->LS1.OSSD.A.1->LS2.OSSD.A.1
X11.OpSafeA<-LS1.OSSD.A.2<-LS2.OSSD.A.2
(repeat for Bs)
However, for some safety devices, this may not work (or it may work, but not reliably). Standard practice is to use a safety relay, or PLC, to combine the OSSDs of multiple safety devices (Light Screens, Gates, etc) into a single OSSD pair that is wired directly to X11.
Typical OSSDs are not isolated or polarity free contacts. They are normally powered internally by the device itself (such as light curtain receiver in this case). So feeding the OSSDs by test output from X11 is usually not an option.
Also OSSDs would have own test pulses so not sure if this would be an issue with X11 - KRC uses own test outputs to monitor for cross channel faults and wrong timing of diagnostic pulses could throw a curveball here...
so for a hardwired solution (without safety PLC), one would normally use safety monitoring relay. This is not a simple safety relay, it is a dual channel device with built in monitoring circuit. This monitoring circuit checks if OSSDs match as well if any expansion relays are working correctly (not stuck on when turned off).
Typical LC monitoring relay wiring would look like this:
Things that connect to rails L3, L4 and monitoring relays 13,14,23,24 are optional (only if high power switching contacts are needed or when one is using additional relays to expand number of available output contacts).
in most cases one could use 13-14 and 23-24 as polarity free dry contacts to connect LC into Operator Safety circuit of the robot.
there is also a requirement for acknowledging operator safety. when this acknowledgement is done externally (as button Start in above circuit) then there is no need to acknowledge it on the robot. this can be configured in Safety Configuration or in WoV project.
Typical OSSDs are not isolated or polarity free contacts.
...how did I manage to get that wrong? 
it depends how and where you wire it....
normally all of the devices include monitoring output (not safety rated) which tells the status of the device (tripped or not). this is what could be wired to regular robot inputs and then you can do with it as you please.
in some cases this may not be available so one can do the same with spare contact of the monitoring safety relay.
and if even that is not available, you are pretty limited. you can monitor system variables that tell you state of the safety input. however, since several devices may be connected to the same safety input, detailed diagnostics would not be possible in this case.
the variables you are looking for can be found in documentation or also grouped neatly in AutoExternal interface configuration screen.
$PERY_RDY
$USER_SAF
$ALARM_STOP
etc.
