Triton: run IOC on Triton control PC: implementation

[Tom-Willemsen]

As a member of the cryogenics team, I would like the Triton IOC to run on the Triton control PC rather than the instrument PC so that I can run diagnostics easily, without depending on which beamline the fridge is on.

Acceptance criteria

• As a user, I can control the Triton system when the IOC is running on the Triton control PC
• As a user, I can see any alarms that my IOC is generating in the alarms view
• As a user, I can create blocks pointing at the Triton IOC PVs
• As a member of the cryogenics team, I can look at archived data for Triton PVs (regardless of which beamline the fridge was on at the time)
• As a member of the cryogenics team, I can view and control PVs from the triton system
• As a member of the cryogenics team, I can configure which beamline the fridge is currently on
• As a developer, I can see IOC logs from the Triton system
• As a developer, I can start and stop the Triton IOC.

Notes

1. The purpose of this ticket is to implement the solution described in the comments of Triton: run the IOC on the triton PCs rather than the instruments #3091 for running the Triton IOC on the Triton's control PC

[DominicOram]

Rough picture of the proposed architecture: (should be covered in linked ticket but add a better drawn picture to the wiki as part of ticket)

Criteria of each group

[FreddieAkeroyd]

I guess configuring the IOC will be via globals.txt ?

[Tom-Willemsen]

Setting the instrument will be done via a PV, see comments of #3091

For the triton there are no other configuration options to worry about (it will always connect to the triton on localhost with a fixed port number)

[KathrynBaker]

This solution is also of interest to the Cryogenics group (as part of a small project) so that they can monitor the systems centrally (not part of the HLM work).

[Tom-Willemsen]

Re-requested by Cryogenics group, so re-proposing.

They say that better remote diagnostics would help them to prevent somewhere around ~1 problem/cycle (where a "problem" has a lost beamtime impact of multiple hours and sometimes days).

Things to do in this ticket:

• Implement service that serves some PVs that we can use to control the "remote ioc"
• Be able to start and stop the IOC via this service we've decided this doesn't really make sense to do in general - the IOC will restart when the configuration changes as normal though.
• Implement gateway which aliases the fixed names to a particular instrument
• Provide some mechanism(s) for configuring the IOC (macros etc)
• Implement access security on the gateway(s) so that the given instrument + cryogenics + us can write but no-one else
• Log values into a local/central archive
• Log values into the instrument archive (maybe not needed?)
  • We have decided not to do this (in this ticket).
• Push alarms to instrument db
• Push ioc status to instrument db
• Push interesting pvs to instrument db