Redundant opening of 13 k A EE switches

  • Slides: 9
Download presentation
Redundant opening of 13 k. A EE switches via Software I. Romera MPE-TM meeting

Redundant opening of 13 k. A EE switches via Software I. Romera MPE-TM meeting September 2014 Acknowledgements: H. Milcent, R. Denz, R. Schmidt, M. Zerlauth 1 v 0

Introduction CERN • Following the incident in April 2011 and the recent observation during

Introduction CERN • 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 13 k. A 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 SIL 2/3/4 implementation but will allow for redundancy for these critical items to the HW loop ivan. romera@cern. ch MPE-TM meeting

Possibility #1 CERN Switch Open Command in case of ‘quench’ detected CMW subscription to

Possibility #1 CERN Switch Open Command in case of ‘quench’ detected CMW subscription to local QPS controllers (i. QPS & n. QPS) ivan. romera@cern. ch MPE-TM meeting SIS

Possibility #1 CERN • PROs • Can capture also the eventual failure case of

Possibility #1 CERN • PROs • Can capture also the eventual failure case of a i. QPS/n. QPS 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 i. QPS and n. QPS 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) ivan. romera@cern. ch MPE-TM meeting

Possibility #2 CERN PIC SCADA CMW subscription to PIC SCADA) Switch Open Command in

Possibility #2 CERN PIC SCADA CMW subscription to PIC SCADA) Switch Open Command in case of ‘quench’ detected PIC PLC CIRCUIT_QUENCH ivan. romera@cern. ch SIS CIRCUIT_QUENCH MPE-TM meeting

Possibility #2 CERN • PROs • ‘Cleaner’ and more transparent implementation • Easier implementation,

Possibility #2 CERN • PROs • ‘Cleaner’ and more transparent implementation • Easier implementation, exploiting existing PIC signals, worked extremely reliable during Run 1 already • CONs • Relies on the opening of the quench loop by i. QPS/n. QPS 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) ivan. romera@cern. ch MPE-TM meeting

Conclusions CERN • Implementation possible but needs careful development and testing to avoid false

Conclusions CERN • 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! ivan. romera@cern. ch MPE-TM meeting

CERN Fin Thanks a lot for your attention! ivan. romera@cern. ch MPE-TM meeting

CERN Fin Thanks a lot for your attention! ivan. romera@cern. ch MPE-TM meeting

Next steps… 2/2? CERN ivan. romera@cern. ch MPE-TM meeting

Next steps… 2/2? CERN ivan. romera@cern. ch MPE-TM meeting