DCS, DOMs and interplay
with Run Control
20/06/12
FV
1
Detector Operation Modes
MAINTENANCE or TUNING
RICH
STRAW
LAV
Any actions allowed
Many active users
RUN DOM
NA62
20/06/12
Actions not allowed
One active user
Shift crew
VF
2
• 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 :
o MAINTENANCE or TUNING
•
•
•
•
o
RUN (or DATA TAKING)
•
•
•
•
o
DCS goal: keeping the detector in predefined and safe state
Actions: any
Number of users: one
Main state of equipment: OFF (but LKr HV ON!)
SAFE_OFF
•
•
•
•
20/06/12
DCS goal: provide stable conditions for data taking
Actions: none
Number of users: one
Main state of equipment: ON
SHUTDOWN
•
•
•
•
o
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
DCS goal: keeping the detector in safest state
Actions: any
Number of users: one
State of equipment: OFF
VF
3
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
4
Detector Operation modes
• TUNING/MAINTENANCE - main mode for run preparation
• RUN - the DCS should guarantee that:
all detector channels are in desired states and
o all parameters influencing data quality are in good (requested) range.
o
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
5
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)
o Depending on situation the operator
o
• either leaves the old recipes without reloading of them or
• downloads (from DB) and apply the new recipes (CONFIGURE command)
o
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
o Send “Detector is ready” signal to Run Control
o
20/06/12
VF
6
From TUNING to RUN and back
TUNING DOM
Shift
crew
takes
control
of
detector
RUN DOM
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
Unlock DCS
commands
20/06/12
READY
GO_TO_TUNING
ERROR
ERROR
UNKNOWN
UNKNOWN
RAMPING
RAMPING
VF
To Run Control :
Detector is not Ready
NA62
detector
state
7
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
o 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.
o
• 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
8
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
9