1. RCMS Structure RCMS Security UserDB Service Resource ConfDB
Sub-System
(Daq)Resources
Security
Service
Resource
Info&Mon
Job Ctrl
Problem
Solver
Controller
Services Connection
Session
Manager
RCMS UI
UserDB
ConfDB
LogDB
Run
Bkkpng

2. RCMS Layout RCMS Services Connection Session Manager UI Services RUs
EVB
Ctrl CS
TRG
DCS
EVF
RUs
EVM
BUs
CS Sub- System
Glbl Mu
Cal
DCS Sub- System
EVB Sub-System
TRG Sub-System
EVF Sub-System
RCMS

3. Interaction with the sub-systems
The Control Network topology of the sub-systems. Possible hierarchies introduced by the DAQ slicing
Commands submission and information (errors, monitor, etc.) collection performances inside a given sub-system.
Where all this is reported? Do we need it?
Interaction with DCS and CS. (?)
EVB
BU Slice X
sub-system BU
EVM RU
Sub-System Controller
DAQ resource

4. Run Sessions and Partitions (i)UI UI
run session A UI UI UI UI
run session B
RCMS
Session
Manager
Session
Manager
Services
Services
Services Connection
EVB
Ctrl CS
Ctrl
TRG
Ctrl
DCS
Ctrl
EVF
Ctrl
BUs
EVM
RUs
Cal Mu
Glbl
EVB Sub-System
TRG Sub-System
EVF Sub-System
DCS Sub- System
CS Sub- System

5. Run Session and Partitions (ii)
RCMS should interact with the Trigger sub-system to get/set the available partitions.
Are they defined and stored in the Resource Service?
Who set the trigger partitions?
The same for DCS.

6. Run Definition CLASSIC Start Stop Start Stop LHC “spill” LHC Start
homogeneous conditions
homogeneous conditions
CLASSIC
Start
Stop
Start
Stop
Run # X
Run # X+1
Change Conditions
Store new conditions
Change data file
LHC “spill”
LHC
Start
Stop
condition Y changed
condition Z changed
Condition DB
dump
conditions
Fast Reset
mini Run A B C D E

7. IMS & Run Conditions
We assume the run conditions coming from all the sub-systems (including trigger and DCS) are managed by the Information and Monitor System. Is this true?
Is the message definition adequate for handling this type of information?
DB performances requirements must be defined much better. If any “natural” hierarchy is defined (e.g. the one introduced by the daq slicing), it can be reflected in the DB design helping in this way the scalability of the system.
The system has O (10000) (?) objects with related status to save every time a dump condition is required.
we could have an incremental dump: we save all the conditions at start time and then after that only the ones have been changed.
we need to know size, types, etc. of the parameters characterizing the detectors setup (HV, LV, P, T, etc.). How we can get them? How fast we can read them? any defined hierarchy?
Same for the trigger system.

8. IMS message definition
T, Type, Id, Specific Fields, Source_Id
Time Stamp
Message Source Id
Message Type:
Errors
Generic
Status Change
Monitor
Message Id
According to Type
e.g. for Errors:
- Severity Level (0=warning)
- Description