1. Barrel RPC Conditions Database
It will hold all data describing the running conditions of the detector:
Main part of the conditions data will be necessary for physics event reconstruction
Other data will be used for error tracking
It is a “trait d’union” between online and offline data
What does that mean for Barrel RPCs ?

2. What we are dealing with
4 layers of muon detectors: in the barrel RPC+MDT
In each layer 12 sectors:
In each sector: 2 RPC chambers for RB1 and RB2
1 RPC chamber for RB3 and RB4
… for a total of 480 chambers

3. RPC system numbers
area covered: 2400 m2
number of RPC chambers: 480
number of strips: ~75.000
number of front-end cards: 4.700
Each chamber has associated with it its story: construction DB
Some of these data will have to be uploaded to conditions DB
Data types (just a first hypothesys): substantially four kinds:
”Geometric” constants
Environmental conditions
Running conditions
“Historical” informations

4. “Geometric” data Main (and primary) task: pass from raw data to tracks
Raw data from RPC: hit address
Chamber ID (2 bytes) and Fired Strip ID (1 byte)
Needed: geometry of the Chamber
From the point of view of fired strip information, RPCs chambers come into 10 main “flavours”, plus some variations (chimneys), differing in dimensions and strip pitch.
Maybe necessary to keep track also of the service position (i.e. for noise studies) …then a factor 2 more types (left and right)
Actually, due to the presence of pre-loaded bars, almost all chambers are different …

5. “Geometric” data Immediate association in the “local” reference system
Hit address
To pass from local reference system to CMS reference system, a point and three angles needed (from alignment?)
In the barrel RPCs are “solidal” with MDT, so this part of the code could be common?
Precision needed: hit information has the spatial resolution of the strip dimension, order of cm
Reasonable to reach an order of mm accuracy

6. Environmental conditions
Essentially temperature, pressure, humidity, needed for correct calibration of the system
Temperature measured: 1 per Chamber (external)
1 per Front-end board
Humidity measured: 1 per gas crate (internal)
1 per CMS (external)
Pressure measured: 1 per CMS
Informations from the gas system: operating conditions, gas flow rate, percentage of recirculation
Hopefully more or less stable: no need to update constants frequently

7. Running conditions Basic information: was the chamber on?
… Each chamber is divided in 2 or 3 DoubleGaps, so needed one information per DG … (maybe, in particular cases, one per SG?)
Operation HV: 1 per chamber, maybe 1 per DG
On front-end electronics: low voltage, threshold on input signals
Possible failures (for instance)
Front-end: broken boards
Strips: “dead” or noisy strips
…..
These should be the direct logging of a diagnostic online system

8. Running conditions
It is an open issue, how often, and in which way, runs dedicated to calibration and measuring of subdetector performance will take place
In this case, do we want also to keep track of a rough performance of the detector (important for estimating the trigger efficiency)?
…Moreover, the information coming from RPCs will be fed into dedicated pieces of electronics (link and trigger boards) to generate 1st level muon trigger
Informations related to connection topology, and problems in these deviced

9. “Historical” informations
Probably useful if one wants to track possible sources of error, or for a better calibration, without accessing the construction DB
For instance:
measured resistivity (even at the level of bakelite sheets)
measured efficiency (or noise) before installation, useful to keep track the need for a different operating voltage or threshold value

10. Conclusions and open issues
At the moment we can define (more or less precisely) the kinds of data we want to keep in the conditions DB
…more feedback needed from people making reconstruction and simulation analysis
Given the data types, frequency of data refreshing in the DB can be inferred
Given the main task of this detector (generate a 1st level muon trigger) needed more feedback from the trigger community
To define how these data can be trasferred (from construction, geometry, etc.) to conditions DB … format, syntax …