Configuration Database

Download Report

Transcript Configuration Database

Configuration Database
David Forrest
University of Glasgow
Scope

The configuration database deals with cabling,
calibration, geometry, alarm handler limits and set
value configuration information only; not data
 Its use cases are useful for offline analysis,
reconstructing the configuration of the experiment
 Eg “Give me the configuration of the experiment at
16:15 on 5th November 2009”
 Database is built on Postgres database management
system and hosted on heplnw17. The database is not
purely relational but also bi-temporal. Please see
previous collaboration meeting talks for a fuller
explanation of this concept and its justification.
Progress
Not done
Task
In Progress
Status
Done
Delegated
Person days
Database Design
Lots
Database Implementation
Lots
Write geometries
7
Reconstruct Geometries
7
Read/write cablings
read/write calibrations
read/write set values
20
7
10
Triggers, constraints and XML DTDs
7
Transactions, rollback, robust feedback
3
Networked calls
5
Documentation
10
Access levels (API, G4MICE, ctrls, det experts)
1
Alarm limits
7
GUI
Remote access webserver
Security
Client apps
21
CM25?
5
Database Functionality

No-one in the collaboration (except me) needs
to know any SQL to use the database.
 They will simply use the same software they
have been using up until now, which will know
how to ask questions of the database
 There is something called an API which
existing programs should communicate with.
This API will translate requests into SQL
 My job is to write that API in one place, rather
than include DB code in many places
(programs)
In picture form
DB Developer
Control
Room
Apps*
DB
Interface
DB
G4MICE
RAL Firewall
Grid Users
*Automatic Recording processes in the control room including James Leaver’s user
interface for set values
Database Functionality 2

Since the last collaboration meeting there has been much progress
 Geometry
- Can now write and read geometries
- We can reconstruct what the geometry was known to be for a given
time. We have a history of state.
We also can update when misalignments are found. We have a history of
those updates. You can reconstruct what was KNOWN about the state of
the geometry at some set of given times, very easily.
 Calibration
- Can now write and read calibrations of arbitrary format
- One default calibration should be maintained by the detector groups but
others can be kept and called specifically
 Set Values
- Can now write and read set values
- EPICS GUI (James Leaver) interfaces with this. Thanks also to Pierrick
& Adam for help with cataloguing many set vals.
Database Functionality 3

Approval has been given in principle
from RAL Networking for a webserver,
subject to satisfactory demonstration of
security. (Contact : Malcolm Ellis)
- This has been a dead weight on the
project up to this point
- I am setting up such a webserver
during this collaboration meeting, for
testing, initially not visible to the world
How do I talk to the database?
Lets use an example of a G4MICE user
wanting to load the configuration of all
the experiments with some conditions
On the API we have methods like this:

getGeometry(Time or run number),
getCalibration(detector, time or run),
getSetValues(time or run), etc for alarm
handler and cabling…also getAll(run)
Use -1

I have almost completed a small web
interface for quick answers on run
numbers etc
Use-2
The user can insert the run number they
wish to read the configuration for into
G4MICE data cards
 An application within G4MICE reads the
configuration relevant to that run number
from the database
 Other data card values can be used to
choose for example non default
calibrations…

Moving over to DB

James Leaver has written a gui for deployment
in the control room which writes set values to
the database instead of having to use
spreadsheets
 Right now this is in prototyping, we have a lot
of manual input which is being replaced bit by
bit by automatic input, so as much as possible
will be automated
 There are checks and constraints defined to
identify sensible input only which will remain in
force even when its automated
Moving over to DB 2
We anticipate making less and less of
this manual input, and making almost all
of it automatic as client apps link up with
the database
 We have already tried uploading set
value configurations from the gui and it
has worked perfectly

Review Feedback




There was a DAQ and controls review following the
last collaboration meeting
The database was included in this review. Myself and
Malcolm Ellis have sent initial feedback to JSG
I was not able to be present at this review however did
provide documentation and was available to answer
any questions put to me on the phone
Felt it would be good to take the opportunity to clarify
here any potential concerns the collaboration may
have, after having read the review
Feedback 2



“The committee [is concerned the] structure of the database would not easily provide access
to online distributions taken at some arbitrary date in the past for comparison with current
data. “
- This has never been within the remit of the database
“Replication of the database to an additional copy accessible externally would mitigate the risk
[of excessive traffic], but the appropriate security measures need to be designed into the
system as a priority.”
- The postgres database management system includes support for defining and
queuing transactions, which are indivisible and isolatable units of interaction, with the
database. It is used commercially for many high performance applications. The API is
also complementary to these concerns. It is unclear to me what added value could be
found in making a second copy of the database, (although on a different note, regular
backups will be made). I am confident that the software is able to meet our
requirements but have neither comment nor criticism of available networking hardware.
“It was not clear either from the presentation that this mechanism allows one capture multiple
possible configurations for the online systems, for instance setup for normal beam data-taking
versus special calibration modes, choose as necessary at run time and then retrospectively
determine which was in force. “
- This is a key motivation for providing time dimensionality in the database and
information can be found in sections 3.2 & 3.6 in the database brief and slide 17 of the
presentation.
Summary
Database is progressing well
 Wish to finish database functionality and
perform stress tests which could be
presented at CM26
 Nevertheless, people should think about
integrating DB communication with their
applications (contact me for info –
[email protected] but this is an
action item for others)

Better Summary
This slide was written *before* the talk was given…and is not
dynamically created at runtime.