1. Acknowledgements: H.Milcent, R.Denz, R.Schmidt, M.Zerlauth

2. Introduction
Following the incident in April 2011 and the recent observation during the CSCM, possibilities for a redundant SWITCH_OPEN command through a SW channels have been investigated
Basic principle is to use CMW to collect relevant information from the QPS/interlock systems to detect a quench loop opening and send a SW command to the/both 13kA EE systems to force a redundant opening
Use of SIS (Software Interlock System) to allow for flexibility and conditioning of signal (with circuit current, non-fail-safe implementation, opening only on-change, …)
Clearly not a SIL2/3/4 implementation but will allow for redundancy for these critical items to the HW loop

3. Possibility #1 SIS Switch Open Command in case of ‘quench’ detected
CMW subscription to local
QPS controllers (iQPS & nQPS)

4. Possibility #1
PROs
Can capture also the eventual failure case of a iQPS/nQPS card triggering but NOT breaking the loop (highly unlikely)
CONs
SW detection of true ‘quench’ is not obvious, as only states can be exploited
Complicated logic needed, mixing iQPS and nQPS acquisitions for a given magnet to avoid false triggers
In case of true quench, PM sending will inhibit sending of Logging Data -> QPS_OK, … not usable
Many subscriptions + internal complex logic (either in SIS or in local QPS GW)

5. Possibility #2 PIC SCADA SIS PIC PLC PIC PLC
CMW subscription to PIC SCADA)
SIS
Switch Open Command in case of ‘quench’ detected
PIC PLC
PIC PLC
CIRCUIT_QUENCH
CIRCUIT_QUENCH

6. Possibility #2 PROs ‘Cleaner’ and more transparent implementation
Easier implementation, exploiting existing PIC signals, worked extremely reliable during Run1 already
CONs
Relies on the opening of the quench loop by iQPS/nQPS and DQQLC transmission (would have worked also for 2011 type of incident but only thanks to even/odd connections)
Additional SW component involved (PIC PLC and PIC SCADA)

7. Conclusions
Implementation possible but needs careful development and testing to avoid false triggers, e.g.
Only send command on change of signals (avoiding dead_locks)
Non-fail-safe implementation to avoid false triggers in case of reboots of SW components,…
Conditioning by circuit current /machine mode to avoid equipment stress/perturbing ISTs,…
Certain development effort, e.g. for (preferred) solution 2:
QPS/EN-ICE:
1-2 days to do development and test in dev environment
Few minutes to deploy it on all sectors, resulting in means an interruption in the LHCLogging, etc.
GTWs are not affected.
SIS:
~1 day to create the logic per circuit, 1 day to test it out
MPE
~ 2 days to finalize implementation and document in ES/FS/ECR
If to be implemented we should decide very soon!

8. Thanks a lot for your attention!
Fin
Thanks a lot for your attention!

9. Next steps…2/2?