TASCA Control System - "Artificial Intelligence"

New section added by JPO on 19th June 2012

Return to Control System main document: Required Functions Top

Return to: Required Functions Sub-document

Up to now we have only discussed "classical" features to be incorporated in the new control system. I.e. functionality similar to what we currently have. But this would be a huge waste of opportunity. Exploring the possibilities of the new system where all (critical) signals are available on the FPGA we should be able to build a system with

1. more "reasonable" interlock generation
2. safer interlock generation
3. much less user intervention
4. better use of beam time (less false interrupts)

This can be done since

1. all interlock signals are feed to the FPGA
2. all critical parameters (target temp, etc.) are available in a single unit (the FPGA)
3. the new system have capacity (if sensibly programmed) to not only act on a single parameter being outside the safe limits, but to consider several parameters at once and then decide how critical the situation really is.

E.g consider what the TASCA crew do when an interlock is generated on (most likely) noise on the macro pulse (MP): We check the beam intensity (NODAL) level and history (stability), target temperature and detector rate. If they are all normal we move the chopper out again and check that nothing looks bad. This could have been done fully automatic by the FPGA provided it has all the relevant signals: If target temperature and avarage beam intensity is well below critical levels it's likely noise and we can defer engaging the chopper, but we raise the "threat level". If it happens again within e.g the next 10 MPs (or whatever we decide) then we (or rather, the FPGA) might want to engage the chopper due to the hightened threat level.

This can be taken much further (but not too much..): We can have a threat level ladder which we gradually climb depending on how serious a certain condition is. Also, the starting point on the lader can dependent on the target and other critical factors. A 249Bq target will start higher than a ordintary 208Pb target, etc.

It is also possible for the FPGA to engage the chopper, then check the following MPs and beam intensity. If all looks well then the chopper is withdrawn again (provided that not some other interlock has triggered in in between). For added safety the threat level could be rised to make the system extra "jumpy" immediately afterwards.

Exploring such possibilities should enable us to make a system which only allerts the user when something is REALLY wrong - e.g. the beam intensity, detector count rate, or target temperature really is too high.

Such real errors happens rather seldom, maybe less than once per day. Thus, it should be possible to operate TASCA without anyone present in the control room. The on-duty crew member can be allerted through SMS, pager, phone app or remote screen (in his/her office or guest room). It should even be possible for the night crew to sleep (on-site). There is no safety gain obtained by having crew in the control room at all times - the target and cave is contained and anything which can go bad either go bad so quickly that there is no way to intervene or TASCA will be isolated and put in safe mode with no more danger. Many crew members are not allowed to enter the cave alone, anyhow, so why should they be present in the control room when all they are allowed to do is to call somebody and wait? The control system will to this much faster and more predictively.

Of course, there is a series of interlocks which always must shut down the beam: If the magnet field is is wrong, gas-pressure outside its limits, vacuum is bad, etc. then something is seriously wrong and system should go to safe mode immediately, totally disregarding the threat lader. But this is easy to ensure and also happens very seldom.

I suggest that we make a flow chart to define how the FPGA system should behave (and be programmed). This should be much more easy to make and read than writing long list of parameters.

-- JonPetterOmtvedt - 19 Jun 2012