Transcript Database

Configuration Database
David Forrest
University of Glasgow
CM24 @ RAL :: 31 May 2009
1
Configuration Database
 Brief overview of the database
 Updated from last time:
- Geometry
- Cabling
- Calibrations
- API
- Performance
 Future Work
2
Overview :: Scope
 The configuration database deals with
cabling, calibration, geometry and set
value information ONLY
 Its use cases are useful for offline
analysis, reconstructing the
configuration of the experiment
 Eg “Give me the configuration of the
experiment at 19:15 on 31st May
2009”
3
Overview :: Temporal Data
 Imagine uploading some calibration valid for a given
month.
 Store the period of validity and label this the valid time.
 Then later we find a better calibration for that same valid
time. We want to keep both, with the same valid time.
 We also store the time the information was given to the
database, which is the transaction time.
 Now we can get the most up to date calibration by
default, but also recall the other calibrations by meta
data.
 Our database is bi-temporal
 Example holds for geometry (eg misalignment) and
cabling also. Not currently implemented for set values.
4
Overview :: API
 There are many applications which will read from and
write to the database
 The database should not make any impositions upon
their design and implementation
 When something is updated it would be easier to
update code in one place rather than in many places,
versions, etc
 So we have an API, which stands for Application
Programming Interface
 The API is also independent of the reading and writing
applications and the database management software.
 My role is not to implement all client applications but
to design, implement and document the DB and API,
so that any number of developers can plug their own
custom applications into it
5
API-2
Database
Developer
Control
Room
Apps
DB API
DB
G4MICE
RAL Firewall
Grid Users
6
Overview :: Implementation
 We use the Postgres 8.3 Database
management software
 The API is a server with code written in
Java using JDBC. C++ code, etc, can of
course connect to it!
 All the client has to do is interpret the
feedback which will be of a guaranteed
agreed format
 I have been building the full database up
incrementally, testing and prototyping as I
go along. It is based at RAL, and can be
accessed remotely
7
Updates :: Calibrations
 It has been challenging to tie down all
detector groups to a calibration format
 So we won’t. The idea now is to have a
flexible calibration format which does not
require us to know the format of a
calibration in advance
 Calibrations can now be a vector of values
of elements of different types – double
floating point number, string, boolean,
integer
 Meta data included + Temporal overlap
8
Calibrations - 2
9
Updates :: Cablings
 Just getting to grips with this recently
 Take detectors as roots of cabling - unless theres a
good use case for the configuration DB storing
detector independent cabling
 Previously had a fairly loose approach
 We now have detector specific cabling schemes – are
these complete (so far as is related to a real use case
of the config DB)?
 Every component of cabling should have a unique ID,
often the serial number. This is unique not only over
all components of same type, but over all
components. Eg so a splitter can be assigned an ID
number for each channel without knowing in advance
the type of device it is connecting to.
10
Cablings-2
Prelim – will likely have a couple of
changes to TOF, KL, and arising from
implementation issues.
11
Geometry
12
Updates :: Set Values
 I know we want:
 Magnet currents (quads, dipoles);
RFCC currents; diffuser thickness;
decay solenoid current(s);
spectrometer solenoid currents; focus
coil currents; target depth & delay
13
Updates :: API
 The API exists now, and sits at RAL
 It really should be moved to a box which is visible to
everyone. Any offers?
 It currently takes a geometry encoded in XML and
translates that into SQL and uploads it to the
database
 XML is standardised and extendable, and highly
recommended as a means of communicating with the
API, which has good XML parsing functionality already
 In an ideal world, for writing data, just send an xml
file and the API knows what to do eg if its geometry,
calibration, cabling etc.
14
Updates :: Testing
 Geometry almost fully implemented, with valid time
(but not transaction time yet) and full module
hierarchy
 I uploaded 60+ geometries and asked typical
questions about the geometry at a given time. Valid
time introduces no significant slow down to Postgres.
Transaction time will increase complexity only slightly
 This still has to be translated from SQL response to
XML, and G4MICE reconstructing the hierarchy may or
may not place further obligations on the database, but
current results are promising
15
Current State + Future Work
 Geometry prototyping is going well
 Would like to upload some calibrations next
 Once cablings are fully prototyped, much of the
hardest work will be done
 We still need people to write code which sends
requests to the API and digests response (no db
knowledge required)
 I am mainly hoping at this collaboration meeting to
better analyse the seams with other systems, eg
G4MICE, control room apps, EPICS, DAQ by
meeting up with JSG, Malcolm, Pierrick, and others
16
Temporal but not temperamental
17