1. DCS, DOMs and interplay with Run Control
20/06/12 FV

2. Detector Operation Modes
MAINTENANCE or TUNING
RICH
STRAW
LAV
Any actions allowed
Many active users
RUN DOM
NA62
Actions not allowed
One active user
Shift crew
20/06/12 VF

3. Detector Operation Mode (DOM)
is a set of rules used by DCS for detector operation in specific conditions. The rules also determine the way how the DCS moves from one DOM to another and communicate with external systems.
Typical DOMs :
MAINTENANCE or TUNING
DCS goal: provide comfortable conditions for tuning or maintenance of sub-detectors
Actions: any
Number of users: many
Main state of equipment: both ON and OFF
RUN (or DATA TAKING)
DCS goal: provide stable conditions for data taking
Actions: none
Number of users: one
Main state of equipment: ON
SHUTDOWN
DCS goal: keeping the detector in predefined and safe state
Main state of equipment: OFF (but LKr HV ON!)
SAFE_OFF
DCS goal: keeping the detector in safest state
State of equipment: OFF
20/06/12 VF

4. Some other definitions
Recipes
is a set of parameters fully defining operation of a sub-system or full detector. This set include states (ON/Off), setting values, alarms thresholds, etc. The recipes are stored in an external data base (ORACLE) and can be edited with dedicated editor, uploaded to the system, modified and saved back to the data base.
Run Type
defines type of physical run foreseen for current data taking period. For example it could be MUONS, LOW INTENSITY, HIGH INTENSITY, “Italo’s run”, etc.
For each Run Type there is corresponding recipes set.
20/06/12 VF

5. Detector Operation modes
TUNING/MAINTENANCE - main mode for run preparation
RUN - the DCS should guarantee that:
all detector channels are in desired states and
all parameters influencing data quality are in good (requested) range.
A deviation from these stable conditions should abort the RUN DOM and move the NA62 experiment node to TUNING DOM
SAFE_OFF - the detector is in the safest state
SHUTDOWN – the detector is in predefined and safe state
20/06/12 VF

6. From TUNING to RUN
The RUN DOM can be initialized in TUNING DOM only by explicit operator GO_TO_RUN command
Before sending the GO_TO_RUN command
Shift operator will take control of detector (one active user)
Depending on situation the operator
either leaves the old recipes without reloading of them or
downloads (from DB) and apply the new recipes (CONFIGURE command)
If after the application of the new recipes
all detector channels are in desired states and
all parameters influencing data quality are in good (requested) range
The system is in READY state and GO_TO_RUN command is available
The GO_TO_RUN command will
Block any DCS commands
Send “Detector is ready” signal to Run Control
20/06/12 VF

7. From TUNING to RUN and back
TUNING DOM
RUN DOM
Shift crew
takes control of detector
CONFIGURE
Run type ?
NA62 detector states
To Run Control:
Detector is Ready
Load new recipes
READY
GO_TO_RUN
Evaluate detector state
Lock DCS commands
READY
Unlock DCS commands
GO_TO_TUNING
NA62 detector state
ERROR
ERROR
UNKNOWN
UNKNOWN
RAMPING
RAMPING
20/06/12 VF
To Run Control :
Detector is not Ready

8. From RUN to TUNING and back
In 2 cases:
A NA62 detector element changed its state from READY to any other state. In other words the conditions:
all detector channels are in desired states and
all parameters influencing data quality are in good (requested) range
are not satisfied
Operator send command “Go_TO_TUNING”
In both cases the DCS will send “Detector is not Ready” signal to Run Control and automatically move to TUNING DOM. This will unlock the DCS commands.
In TUNING mode an operator can cure the problem
Once the NA62 detector is in READY state the system can be returned to RUN mode
20/06/12 VF

9. Exchange of information between DCS and Run Control
Despite of similarity in technology the Run Control is an external system for DCS, like DSS, Gas Control etc.
As with the other external systems the exchange is based on defined in advance (hopefully short) list of items and communication software (DIM or DIP). The exchange mechanism should not bind one system to another and allow independent development/evolution of both of them.
20/06/12 VF