ESS Cryogenic Controls Design

Abstract

The European Spallation Source (ESS) is a neutron-scattering facility funded and supported in collaboration with 13 European countries in Lund, Sweden. Cryogenic cooling at ESS is vital particularly for the linear accelerator, the hydrogen target moderators, a test stand for cryomodules, the neutron instruments and their sample environments. The paper will focus on the control system design for the different cryogenic subsystems, hardware and software selected, industry and in-house development, advantages and disadvantages of the chosen setup and operational experience. There is also a lessons learned, feedback from providers and stakeholders and an outlook for further development described.

Introduction and system overview

ESS cryogenics system

The European Spallation Source (ESS) requires cryogenic services in all major technical parts of the machine – in the Accelerator for the superconducting cavities, in the Target System for neutron moderators and in the Neutron Instrument suites for sample environments. The cryogenic system is a mix of closed loop and open loop systems, commercially obtained plants as well as in-kind delivered cryostats and equipment, comprising vast cold and warm distribution, cold and warm storage tanks, purification and other auxiliary equipment. It has been described in a number of papers as for instance in [1, 2].

The cryogenic system has been arranged in various functional subsystems for different procurements or in-kind deliveries. Based on the needs at ESS and the estimated lead time for having them at site, installing and commissioning them they were specified at very different times and maturity levels of the ESS controls set-up. Mainly for this reason we can see an evolution of the specific approach regarding scope split and software tools used for the cryo controls of each subsystem. This applies both, for industry supplied and in-house developed systems.

A block diagram of the ESS cryogenic system as shown in Fig. 1 and functional descriptions have been published in numerous papers like in [1] or [3].

Fig. 1

ESS cryogenics system block diagram

As the cryogenic consumers have very different technical requirements and schedule demands, it was decided at an early stage to provide cryogenic cooling with three independent helium refrigeration plants: the Accelerator Cryoplant (ACCP), the Target Moderator Cryoplant (TMCP) and the Test and Instruments Cryoplant (TICP). Furthermore there is an extensive cryogenic distribution system (CDS) connecting the cryoplants with their consumers. One of the main consumers is the Cryogenic Moderator System (CMS), comprising a liquid hydrogen loop for the moderators in the Target Station. Furthermore there is the cryomodule test stand and the superconducting linac as main consumers. The controls for cryogenic equipment in the test stand and linac are shared with the respective cryo distribution for it.

The ACCP was the first high value procurement of the ESS, apart from the building and construction contract. The ACCP is by far the most complicated of the cryoplants with the most machinery and complex controls, due to its cold compressor chain. It had the longest lead time, which is the reason it was specified and prepared for procurement very early on in the project, in 2014, when the ESS Integrated Controls Systems (ICS) Division was not yet staffed up and detailed requirements of controls integration on EPICS (Experimental Physics and Industrial Controls System) level were somewhat unclear. The other cryoplants were specified a year later with a slightly improved view on how these systems should be tied into the ESS controls infrastructure.

The CDS for linac and teststand and the CMS are in-kind contributions that include controls only to a minimal extent. The CMS controls are completely developed at ESS in-house, the CDS controls by the directly contracted company Evopro with substantial support by the ICS Division and relevant stakeholders.

EPICS and related tools as ESS wide standard

EPICS is a set of software tools and applications used to develop and implement distributed controls systems. There are standard EPICS modules to communicate with devices such as PLCs or other network devices [4].

At ESS we use a site-specific EPICS environment (e3, or ESS EPICS Environment) which is a standardized way of building and packaging EPICS modules [5]. This functionality fits into a toolchain that ESS has developed to deploy IOC (Input Output Controller) configurations on real machines or virtualized grids. The toolchain furthermore contains the

• ESS Naming Service [6] for all PVs (Process Values) in the network,

• CCDB (Controls Configuration Data Base), [7] to model our controls system,

• CSEntry [8], an infrastructure tool to manage components and create IOC virtual machines,

• IOCFactory [9], a tool to configure and deploy IOCs in the E3 environment,

• PLCFactory [10], a tool to generate the PLC-IOC communication interface code,

• CSS (Control Systems Studio), a tool to create the operator screens and faceplates

The ESS controls systems consist of highly specialized, scientific style applications like the high precision timing, proton beam instrumentation, neutron choppers that rely on FPGA (Field Programmable Gate Array) and/or IOC controls on one hand and classical process style applications like HVAC (Heating, Ventilation and Air Conditioning), Cooling Water, Vacuum or Cryogenics that rely on industrial PLCs on the other. The HMI (Human Machine Interface) or OPI (OPerator Interface) for all applications is enforced to be EPICS based for the entire facility.

Furthermore, ESS has established a set of rules and guidelines for creating PLC code.

Controls setup between ESS and Cryoplant vendors

The Cryoplant contracts were set up as turn-key deliveries, i.e. the suppliers were to provide a controls system as per the ESS specification containing all, from the hardware process devices through PLC and IOC up to the GUI (Graphical User Interface). Each individual cryoplant was specified and ordered at different times, based on the expected delivery time and the maturity of the overall design. Consequently, the ESS provided supporting software tools like e.g. PLCFactory had different degrees of maturity. That is now reflected in different appearances and capabilities for operators in every subsystem (Fig. 2).

Fig. 2

Layer architecture of the ESS cryogenics control systems

All relevant “business logic” for Cryogenics happens on PLC level. The EPICS layer is used for the GUI and related applications like archiving. There are no control functions in EPICS.

Evolution of commercially obtained Cryoplant controls systems

Accelerator Cryoplant

Controls description

The accelerator cryoplant has been procured from Linde Kryotechnik AG in Switzerland (LKT). It is a closed loop system, cooling the superconducting part of the ESS proton linac, cryomodules with elliptical and spoke cavities, and the interconnecting cryogenic distribution system. It provides cooling at the cavity operating temperature of 2 K, the shield temperature at ~ 40 K and liquefaction load for the power couplers [11].

The ACCP Control system is Siemens based. The main PLC (in CC1) is a Siemens SIMATIC S7–400. To this PLC several remote IOs are connected. This PLC also communicates with S7–400 PLCs that controls the HP compressor with its oil system and the S7–400 PLC that controls the LP and SP compressors with the related oil system. The logical layout of the setup is displayed in Fig. 3.

Fig. 3

Simplified control systems architecture ACCP

The coldbox and warm compressor station are located in two different buildings which is the reason for the fibre connection between CC1 and TB7. At the time being the fibre connection is not redundant but work is ongoing to have a redundant fibre connection between the buildings, possibly via two completely different routes. The rest of the system relies on a single Profinet network.

The PLCs for both the warm compressor system and the main control system are developed in Step 7 and CFC v9 (Continuous Function Chart version 9). Initially, there was a CFC version difference between the warm compressor PLCs and the main PLC but this was resolved avoiding having two different PLC engineering stations.

The ACCP system was ordered early on in the project, before there was a good uniform standard on how the EPICS integration should be done, leaving much in the hand of the supplier. Linde choose to contract Cosylab as the EPICS integrator for the ACCP. This resulted in that all the OPIs were made in BOY (Best Opi Yet), an HMI system for EPICS developed in large parts by Cosylab. Since BOY is not ported to the new version of CS Studio, Phoebus, ESS is forced to redo all the OPIs for the ACCP. Although technically not overly complicated this is a large work effort we hope to complete in 2021. The IOC was also made by Cosylab using their internal tools, resulting in difficulties (compared to PLCFactory) to update and extend the IOC. Updating and adding PVs is currently very cumbersome in the ACCP, requiring a number of manual failure-prone steps. If only one step in updating the variable array size is forgotten or wrongly performed the entire controls system update fails.

Also, the PLC-IOC communication driver chosen by Cosylab has presented ESS with some challenges, particularly synchronisation issues for commands and parameters. Lacking an existing ESS standard at the time, Cosylab needed to work with a special “Load to PLC” button, see also section 2.1.2. The reason for this button is that the IOC to PLC communication is cyclic, meaning every parameter and command is sent in every communication cycle even if there has not been any change. This happens every ~ 100 ms. The PLC contains code that permanently checks the difference between its current parameter set and the new exchanged one. But only when the “Load to PLC” button is pressed, the PLC accepts the changes and implements them to the running program. This complicates the PLC code substantially.

The main PLC in CC1 interconnects the ACCP control system to EPICS. The main PLC also takes care of the communication with the two warm compressor PLCs. There is no direct communication from the warm compressor PLCs to the EPICS system.

The ACCP EPICS integration runs in a single IOC. Initially this IOC was running on a single machine located in CC1. This has then been moved to the ESS server virtualization environment to improve stability and maintainability.

Operating experience

The first iteration of the OPI was implemented in a way that forced the operator to always push a button in the OPI to download any changes to the PLC, the “Load to PLC” button. This behavior was suboptimal and could sometimes result in unpredicted behavior. If the operator forgot to push the “Load to PLC” button, the changes were not sent to the PLC. If another change was made at a later time and the load button was pushed this meant that the old and new changes were sent to the PLC which could result in very unanticipated behavior of the system. This has since then been reworked. Today the system allows the operator to have direct manual control over valves and some other control objects like starting step chains (i.e. no “Load to PLC” needed). If other changes are made, for instance on controller settings, these changes have to be pushed to the PLC by means of the “Load to PLC” button. This is still not optimal but it is an improvement. This system still requires discipline of the operator which in stressful operation scenarios isn’t always the case, especially if the operator is new to the system.

The overall layout of the OPIs is mostly good, with a clear idea that the process flow goes horizontally and a uniform header with drop down menu navigation. This makes the visualization of the process easier, especially since we have a 3 × 2 screen array in the LCR (Local Control Room) putting the different OPIs side by side giving a nice overview of the process (see Fig. 4). Other screens are confusing and unnecessarily difficult to understand and will be optimized at the occasion of the OPI update from BOY / Eclipse to Display Builder / Phoebus in 2021.

Fig. 4

Operator screens for the ACCP in the local control room

Test and instruments Cryoplant

Controls description

The Test and Instruments Cryoplant (TICP) was delivered by Air Liquide Advanced Technologies in Sassenage, France (ALAT). The TICP cools the Cryomodule Teststand in a closed cooling loop, providing cooling at the same temperature levels as the ACCP, at 2 K for the cavities, ~ 40 K for the shield and liquefaction for the power couplers. Additionally, the TICP can run as a simple helium liquefier to provide liquid helium in mobile dewars to the Neutron Instruments Sample Environment. It also comprises a helium recovery system, an external purifier and a filling station [12].

The TICP control system is based on Siemens S7–1500 PLC systems. Field equipment is connected by means of remote IO, Profibus and several IO modules connected directly to the CPU backplane. The overall logical layout is depicted in Fig. 5.

Fig. 5

Simplified control systems architecture TICP

As the warm and cold parts of the installation are located in two different buildings the TICP does also have a dedicated fiber connection between them. The TICP has two PLC CPUs, one in the Warm Compressor Station (WCS) and one in the Coldbox System, each connected to its own dedicated IOC. Both IOCs are deployed in the ESS virtual server environment. The IOCs for the TICP were developed by ESS.

The PLC code for both PLCs has been developed in Siemens TIA Portal v15.1 (Totally Integrated Automation Portal). Initially it was made in v14 SP1 by ALATs subcontractor ICONE but has later been upgraded by ESS. Most of the Air Liquide code has been implemented in ladder. ESS have made several updates to the initial control logic, migrating some of the code from ladder to SCL (Structured Control Language).

Operating experience

When the system was handed over to ESS there was a limitation to the system only permitting one open OPI screen at the time. A minor adjustment was made to allow to have two open OPI screens. Due to a poor implementation decision, if any shortcuts were used in the OPIs, both the open screens would change. There was also a side menu that was not optimal, see Fig. 6 for the original OPI layout delivered by ALAT. This has now been corrected by ESS and at the same time the navigation of the system has been aligned to the ACCP and TMCP appearance with a common header and drop-down menu, see Fig. 7.

Fig. 6

Original operator screen in TICP by Air Liquide

Fig. 7

Revised operator screen in TICP

Another difference between the LKT and ALAT OPIs are how they handle controllers. In the LKT system there is a controller symbol showing the controller and its interconnections (Fig. 8). In the ALAT OPIs the controller is integrated in the faceplate (Fig. 9) of the controlled object (Fig. 10), this is an disadvantage when it comes to clarity and overview of the system, which is especially true when it is not obvious that an object is controlled.

Fig. 8

Controller symbol ACCP

Fig. 9

Controller faceplate TICP

Fig. 10

Controlled objects TICP

They way that PLC connection is made, all PVs are directly controlled. There is no need to push a “Load to PLC” button. As soon as the operator presses “Enter” the new value is loaded to the PLC which was possible thanks to the improved PLC-IOC communication as the IOC and communication handling was provided by ESS for the TICP. Another good thing about the ALAT PLC implementation is the Graph like structure of the PLC code where all steps are propagated to the OPI and can be viewed in the OPI. With this information it is possible to see where in the program the PLC is and it is possible to cross reference with the PLC code documentation what conditions need to be met to move along. This could of course be optimised with a graphical representation of the controls step chain in the OPI but it is a good starting point.

Target moderator Cryoplant

Controls description

The Target Moderator CryoPlant (TMCP) has also been delivered by Linde Kryotechnik AG in Switzerland (LKT). Its only function is to cool the liquid hydrogen loop in the CMS, described in section 3.3. and the long cryogenic transfer lines interconnecting the units [13].

Like ACCP, it is based on a Siemens SIMATIC S7–400 and also the logical layout is similar to the ACCP. The main PLC is located in CC1 and is interconnected with several remote IOs over Profinet. There are also two compressor skids equipped with Siemens SIMATIC S7–300 PLC communication with the main PLC via Profinet. The system is divided between three different buildings. The warm compressors and coldbox share the same buildings as the ACCP and TICP but in addition there is also a control cabinet (CC2) in the Target Building interconnecting to the Cryogenic Moderator System (CMS), see Fig. 11. The three different location are interconnected via dedicated fiber connections.

Fig. 11

Simplified control systems architecture TMCP

The TMCP also had a dedicated IOC server located in the CC1 cabinet to run the IOC. Like the ACCP and TICP this IOC has been moved to the ESS VM (virtual machine) environment to improve stability and maintainability.

The main PLC code is written in CFC v9 and has been developed by the same LKT subcontractor as for the ACCP, iSA GmbH.

Operating experience

Since the TMCP was ordered later than the ACCP in the project, the OPIs are made in CSS Display Builder instead of BOY which makes them compatible with CSS Phoebus. But the control philosophy is the same as with ACCP meaning that there is a “Load to PLC” button, introducing the same operator challenges. The OPIs share the same horizontal design as the ACCP. Other than this, ESS have not run the plant to the same extent as the ACCP and TICP and have hence not as much operating experience with the plant making it difficult to point out any other pros and cons of the controls.

Evolution of inhouse developed cryo-related controls systems

Pure helium storage

The pure helium storage (PHS) system consists of 19 × 70 m3 tanks that are capable of holding the entire ESS helium inventory. The control system for the PHS tanks is developed inhouse and is based on a Siemens S7–1500 PLC and four valve control cabinets with remote IO modules, see (Fig. 12). The system has a dedicated fiber connection to the technical network.

Fig. 12

Simplified control systems architecture PHS tank farm

The PLC code is developed in TIA Portal v15.1. This was one of the first systems developed by ESS and has “set the mark” for many other systems. The unified OPI elements were first deployed with the PHS system.

Auxiliary systems

Auxiliary systems that cryogenic operations at ESS depend on are the electrical distribution system, HVAC and Cooling water. The electrical distribution system is a ABB SCADA (Supervisory Control And Data Acquisition) system. As of today, there is no EPICS integration in the ABB SCADA system but this is planned in the future.

The HVAC and Cooling water systems both run on Siemens PLCs and are developed in TIA Portal. After the delivery of these systems, ESS have assisted the system providers with EPICS integration enabling us to control these systems from a CSS OPI.

Cryogenic moderator system

The main function of the CMS (Cryogenics Moderator System) is to provide moderating media for the production of cold neutrons and remove the resulting neutronic heat load [14]. Liquid hydrogen is used as the moderating media due to its ability to slow down fast neutrons. The hydrogen is cooled down and condensed by a cold helium circuit, provided via long cryogenic transfer lines by the TMCP, described in section 2.3. Part of the TMCP, the jumper spool box, is located next to the CMS cryostat and used for acceptance testing the integrated TMCP-cryodistribution-system, load balancing and controlled cool-down and warm-up of the CMS. For these functions some of the control valves in the jumper spool box of the TMCP are directly controlled by the CMS.

The cryogenic system can be divided into several subsystems. The first subsystem consists of a gas management panel for medium supply:

• Hydrogen, used as moderating media

• Helium, used for purging and inert atmosphere in vent lines (not cold helium for cryogenic cooling)

• Nitrogen, used for purging and inert atmosphere in hoods in the CMS

• Cooling water used for the cryogenic hydrogen circulator cooling

The second subsystem contains the main components of the hydrogen circuit which includes two cryogenic circulators, a thermal pressure control buffer with heating elements and valves, a hydrogen ortho-to-para converter and hydrogen-to-helium heat exchangers that also represents the physical interface with the Target Moderator Cryogenic Plant (TMCP).

The distribution box and hydrogen transfer lines represent the third subsystem, connecting the CMS cold box and the moderator plug via welded connections and jumper pipes with bayonet couplings. The manifold is located in between the moderators and the CMS cold box.

More equipment will later be tied into the system, specifically an ortho-para measurement system (OPMS) and a moderator load simulation heater. A simplified controls architecture is displayed in Fig. 13.

Fig. 13

Simplified control systems architecture CMS and related systems

CMS control system (CMSCS) code management

The CMSCS is the first modular PLC based control system at ESS. This means that the OPI elements, the EPICS integration and the PLC code (that is responsible for the EPICS communication) is generated by PLCFactory from a central modelling tool CCDB.

There is a module package for every field object (valves, motors, heaters, controllers, measurements) that consist of OPI faceplate/block icons, EPICS variable definition files and PLC EPICS integration code. By using the modelling tool any control system backbone can be easily created using these packages and the only thing that the PLC developer has to focus on is the actual PLC business logic, connecting hardware addresses for I/Os, creating control sequence and automatic operation code.

PLCFactory generates the whole IOC DB, EPICS startup file and also generates the PLC code that maps the variables between the IOC and PLC instances. The PLC gets this generated code through external source files.

Alarm management for CMS

The alarm configuration XML file for the Phoebus alarm service is also generated by PLCFactory, based on a model in CCDB. This makes the alarm management easier to create with unique guidance information for every alarm PV. There is also a possibility to connect the Alarm event with the ESS Slack messaging service, so the operators get notified even when they are not watching the control screens.

CMS OPIs

With the CMS system, ESS has started with the development of our inhouse unified OPI elements with corresponding PLC modules for different device types. This has evolved into, for example, control valve modules with integrated PID control, both manually and programmatically controllable, see Fig. 14. There is also built in support for switching between three different PID parameter sets and the possibility to change the process control variable between three different measurement devices (Fig. 14). Furthermore, there is the possibility for purely manual control. A lot of effort has gone into the modules to make them as modular and flexible as possible, so that they are easy to be used as templates for future projects at ESS.

Fig. 14

Control Valve with PID controller and the PID configuration

The faceplate for a measurement gives a lot more information than those for the cryoplants and permits to force a value that can be used e.g. for a controller input (Fig. 15).

Fig. 15

Pressure Transmitter Faceplate

Control experience

The CMS is currently in a test phase in Jülich/Germany, where the CMS is tested with cryogenic nitrogen. The CMS is not yet complete, the control system and the hardware is still under development.

The test system has the following hardware parts:

• CMS Coldbox, and vacuum system

• Water cooling system for the hydrogen pumps

• Gas management panel

• Temporary mixing system (local “TMCP” replacement for liquid nitrogen)

In the control system we have:

• Two local control stations with the OPIs and trends (Control System Studio Phoebus)

• Local data archiver (Archiver Appliance)

• Local alarm server (Phoebus Alarm Service)

• EPICS IOC

• PLC control system using the CMS Main Cabinet PLC (TIA v15.1).

Connections between cryo control systems and between them and the broader ESS control system

Communication requirements between subsystems

All the cryogenic refrigerators are stand-alone systems that are tested with its incorporated test equipment with their individual control systems. Other systems that interface with the cryoplants, particularly utilities like cooling water, electrical power, instrument air, liquid nitrogen but also the pure helium storage tank farm with dedicated gas management panel have their own controls that do not necessarily need to communicate with the refrigerators controls.

However, for useful interaction with the cryogenic clients some signal exchange is helpful or even required. The ACCP, for instance, should send a “CRYO READY” signal or a “CRYO TRIP” signal to the SRF (Superconducting Radio Frequency) controls for starting or stopping RF power. In case of the TMCP and the CMS even more signal exchange is required. The TMCP consists not only of compressor system and coldbox but also a jumper spool box that is directly interfacing the CMS cryostat via U-tube jumper connections and that is 340 m of cryogenic transfer line away from the TMCP main coldbox. This is one of the challenges, making the control concept of the TMCP and CMS more complex [15]. The valves of the jumper spool box will be controlled by the CMS. The TMCP can incorporate pre-emptive controls in preparation of a beam trip, when the cryogenic load reduces suddenly but due to the long distances from target moderator to CMS and from CMS to TMCP there is some warning time.

Signal exchange between different control systems

The most important signals, especially safety function related, are hard-wired through copper cables. Significant control function signal exchange, is done on a PLC level. Even signal exchange for overarching controls, connecting different functional units, is done either hard-wired or on PLC level. There is currently no signal exchange between PLCs only foreseen on EPICS level.

The signal exchange between PLCs happens on the PLC-PLC virtual local area network (VLAN).

To be able to visualize and archive process variables from the PLCs we have to develop EPICS IOCs. These IOCs are used to map the PLC variables to the EPICS world. We use TCP (Transmission Control Protocol) socket communication to send data to the IOCs and we use Modbus TCP to receive data from the IOCs. For selected applications we can also use OPCUA (Open Platform Communications Unified Architecture) for bidirectional communication.

Operator Panels can be deployed and executed anywhere in the whole ESS facility through the Technical Network (see Fig. 2).

Conclusions

Lessons learned

From the previous sections it becomes clear that the early developed cryogenics controls are not optimal. Some things can be improved (see also following section 5.2.), some reworked, some cannot be changed with reasonable effort and need to be accepted. But we can try to learn from our experience for future projects.

First we can ask a quite fundamental question: Why is EPICS used as the front end interface for conventional process control systems? There exist much better developed, standardised and regularly maintained solutions on the market that both, Cryoplant suppliers and process control personnel, developers, engineers and operators, are familiar with to a larger extend than with EPICS. The choice of EPICS as THE sitewide one-and-only tool is at least questionable, looking at the implications for typical industrial and conventional control systems like Cryogenics.

When the choice for a tool like EPICS, requiring substantial integration and customisation effort is made, an early development of a tool chain is instrumental. “Hand-made” solutions for fundamental support functions like PLC-IOC communication are nearly impossible to change later and are very cumbersome to maintain.

The software group developing the tool chain needs to include personnel that are actively using these tools. Sufficient “EPICS-literate” people in the Controls Division are required early on in the project, to develop these tools, but also support the other sub-projects, for instance in design reviews and discussions with commercial Cryoplant suppliers.

For developers a style guide, which existed already very early on in the project, is not sufficient as it always leaves much room for interpretation, lacks elements and detail. It is much better to have an OPI library with functioning templates and modules with sufficient flexibility incorporated. The OPI library we have now contains not only colours and distances between objects but functional CSS displays for every device type like valves, motors, heaters, different type of measurements etc.

At the time of agreeing with Linde, provider of the two largest cryoplants, about the PLC programming software the now rather dated CFC seemed like a good solution due to existing experience and copy-paste-ability from similar projects. With the knowledge of today it was better to enforce TIA portal as it is used as a site-wide standard and is more maintainable by ESS personnel. STEP 7 as programming environment is phasing out and so is the use of Siemens PLCs S-300 and S-400. The use of S-1500 should have been enforced, which is also favourable in terms of spare parts.

Suggestions and plans for future improvements

One of the biggest issues with our cryo control systems today is that all of them are made in a different way, particularly all the OPIs. It is our goal to have a similar look and feel for the control elements and faceplates on all systems, which also means recreating a lot of the cryoplant OPIs.

Furthermore, the OPIs of the commercially sourced cryoplants lack transparency. It is not always obvious to the operator why the plant behaves or not in a certain way. We would like to increase the systems transparency by showing more in-between-steps and PLC internal calculations on the OPI level.

Another issue is that the ACCP OPIs are developed in BOY but ESS has taken the decision to only develop and support the Phoebus version of CS Studio, which does not support the BOY OPIs. The decision is well motivated due to serious performance issues in the earlier CS Studio distribution Eclipse. This will force us to migrate the ACCP OPIs from BOY to Display Builder to be able to use them. Given the complexity of the ACCP control system this will be a challenge but also an opportunity to get the OPIs into a state that will be applicable on the rest of the OPIs and make the cryo control system more unified.

One of the biggest “construction sites” in our controls is the alarm handling. Today all the different control systems have their own alarm handling. The ACCP and TMCP have a lot of warnings and alarms with very little guidance on them. As for the TICP, there are fewer alarms and good guidance on each alarm but the visualization of the alarms requires some work. We need to unify the alarm handling and include crucial information for the operators like thresholds, possible alarm reasons, remedies etc., all information we have today in documents but not in the alarm handler. It was also much better had we some kind of general alarm channel where all major alarms are propagated regardless of the source system. This channel should include crucial alarms for all cryogenic and related systems like utilities and ODH (Oxygen Deficiency Hazard) systems. Then we could have an alarm channel on each individual workstation for all alarms, including the minor ones, but only for the subsystem this individual workstation is designated for. This feature seems to work better in the Phoebus version of CS Studio.

In section 2.1.2. the “Load to PLC” button in the ACCP controls system was described. For an operator this could be quite confusing, especially when it comes to the different responses depending on which parameter is changed. For some control elements the change is instantaneously, in others the change has to be pushed to the PLC. In the long term we want to get rid of the “Load to PLC” button in ACCP and TMCP but it will be a huge effort if at all possible. In the short term we can at least make it crystal clear to the operator, by means of appropriate faceplate design, when the “Load to PLC” button needs to be pushed and when not.

There is quite a pile of work for us and there will certainly be more things to be improved but transparency, similarity and maintainability will pay off in the end. We have no timeline for completion of these tasks as they are naturally not prioritised very high when resources are scarce. It will be an ongoing effort for the cryogenics operation and controls teams.