1. Industrial Power Supplies Observations from the survey responses. Observations per commercial vendor. Engagement outline with commercial vendors.

2. Observations from the Survey Can you imagine replacing your XXX powering system with… Generally satisfied or too heavily invested to change. CAEN, Wiener and ISEG live on. New commercial hardware/vendors to incorporate in fwJCOP? Wiener(/ISEG) MPOD? Bulk LV power supplies (PH/ESE talk), control interface? Industrial power supply connectivity CAN and Ethernet. Slight prevailing trend migrating CAN -> Ethernet. CAN free future possible? Environmental constraints Rad/Mag tolerant CAEN/Wiener hardware acceptable. No step change in environments. Really? Higher luminosity, higher energies? New functional requirements More power. Linux support Windows servers required? No complexity with distributed client/server with OPC-UA (compared to OPC-DA).

3. Observations per commercial vendor CAEN Readout too slow. New CAEN hardware models to support. Mainframe firmware is too ‘black box’. Force log off of mainframe sessions. Intermittent board comms loss. WIENER Water leaks. Insufficient granularity in monitor/control parameters. Connectivity problems on restart. Commands lost. ISEG Poor performance (readout? Stability?), improved now. PEAK USB/CAN gateway only. SYSTEC support desirable (and Anagate?).

4. OPC-UA servers: CAEN, WIENER, ISEG. 2014 2015 2016 Start of LS2 End of LS2 Now Agreement with companies established Collaboration ATLAS-EN/ICE for the development of the QUASAR FW QUASAR FW is ready Start of collaboration with ISEG on OPC UA server using the FW. Start of collaboration with CAEN and Wiener on OPC UA servers using the FW. OPC UA Servers are ready for deployment OPC UA Servers are commissioned OPC DA Servers are decommissioned

5. End

6. OPC for Commercial Power Supplies Major investment of the Experiments in commercial power supplies (>15MCHF) -> Prior importance to have proper integration into the DCS -> Currently OPC Data Access (DA) However, DA is being phased out -> Need to move to OPC Unified Architecture Previous model whereby companies developed the servers very inefficient Black-box, not real software expertise in company, issues impossible to reproduce in lab setups Decision to develop the OPC servers at CERN in collaboration with the companies

7. Collaboration Overview Within CERN EN-ICE and ATLAS identified a common interest in OPC-UA middleware. Created QUASAR, a framework which provides consistent implementations of OPC-UA servers. Used to create numerous OPC-UA servers in EN-ICE and ATLAS. KT involved to assist with open sourcing QUASAR (CERN I.P. export) LGPLv3 licensed. Outwith CERN Planned collaborations with CAEN, Wiener and ISEG. CERN to implement ~80% of device logic, expert knowledge required from commercial partners for 20% optimisation. Per-vendor collaboration agreements to be negotiated (with EN-ICE, KT and vendor) to agree on goals and responsibilities of collaborations.

8. QUASAR FW Architecture OPC-UA server toolkit (C++) – Unified Automation LoggingSecurity (X509 certificate handling) XML Configuration Server meta- information Device Logic (Custom code) Hardware access layer (device I/O) – provided by vendor OPC-UA client Hardware Common namespace items and Namespace utilities Commercial toolkit Common components made at CERN Hardware specific logic, Expected ~80/20 CERN/vendor split 100% vendor Goal: To provide homogenous OPC-UA server implementations based on shared components. Delivered via the OPC-UA server generator framework.

9. OPC UA Timeline 2014 2015Now 2016 Start of LS2 End of LS2 Agreement with companies established Collaboration ATLAS-EN/ICE for the development of the QUASAR FW QUASAR FW is ready Start of collaboration with ISEG on OPC UA server using the FW. Start of collaboration with CAEN and Wiener on OPC UA servers using the FW. OPC UA Servers are ready for deployment OPC UA Servers are commissioned OPC DA Servers are decommissioned