Transcript transparencies - Indico

The DCS Databases
Peter Chochula
31/05/2005
Peter Chochula
Outline
• PVSS basics (boring topic but useful if one
wants to understand the DCS data flow)
• Configuration Database
• DCS Archive
– Architecture
– Access to the DCS archive
• Current status
2
31/05/2005
Peter Chochula
The PVSS Architecture
User Interface
Manager
User Interface
Manager
Control
Manager
Data
Manager
Driver
User Interface
Manager
API
Manager
Application Layer
Communication and
Storage Layer
Event
Manager
Driver
UI Layer
Driver
Driver Layer
3
31/05/2005
User Interface
Manager
Peter Chochula
User Interface
Manager
Control
Manager
Data
Manager
Driver
User Interface
Manager
API
Manager
Event
Manager
Driver
In a scattered
In
a simple
system,
thesystem
all
managers
managers
canrun
runon
the
same machine
on dedicated
machines
Driver
4
31/05/2005
User Interface
Manager
Control
Manager
Peter Chochula
In a distrubuted
User Interface
Interface
systemUser
several
Manager
Manager
PVSSII systems
(simple or scatered)
are interconnected
API
Manager
Distribution
Manager
Data Distribution Event
Manager Manager Manager
Driver
Driver
Distribution
Manager
Driver
5
31/05/2005
Peter Chochula
Remarks
• The DCS configuration is not static and will
change in time
– The managers may be scattered if needed
– Individual systems may be split into distributed
system, or joined together
– Devices might be added/removed, channel
assignment might change
• At present time we expect the global DCS will be
formed by a distributed PVSS system
consisting of individual scattered systems
6
31/05/2005
Peter Chochula
PVSSII basics - Datapoints
• PVSS data is stored as Datapoints (DP) of a given
Datapoint Type (DPT)
• DPT represents data structure of the device
– User definable
• DP contains information related to an instance of a
device (similar to Objects and Classes)
– DP can contain many read/write parameters called Datapoint
Elements (DPE)
– Possible DPE types include char,integer, float, boolean … and
arrays made of them
– DP contains configs, which are defining its behavior (e.g.
archiving, smoothing, alarm handling etc.)
– Several status bit indicate the quality of acquired data, etc.
7
31/05/2005
Peter Chochula
Example Datapoint
System1:TestFloat1:floatvalue
SystemName:DPName:DPE
Value
DPT
DP
DPE
Config
Timestamp
8
31/05/2005
Peter Chochula
Remarks
• The full Datapoint name includes the
system name. This can change with time if
the system gets distributed
• An alias name is available for each DP
and can be used to simplify its tracking
(e.g. if a device channel assignment
changes within a detector)
9
31/05/2005
Peter Chochula
DCS Databases
• Two databases are essential for the DCS
operation
• Configuration database stores :
– Static settings (channel assignments, board
configuration…)
– Dynamic settings (alarm limits, voltage set values,
FERO parameters…)
• DCS Archive stores:
– Measured values
– Alarms
10
31/05/2005
Peter Chochula
The DCS configuration database
• Configuration of all DCS devices is stored
here
• Different versions (recipes) exist for
different operation modes (calibration,
cosmics, collisions…)
• Recipes can be changed during the
operation (e.g. HV ramping through the
intermediate state)
11
31/05/2005
Peter Chochula
The DCS Archive
• Designed to store measured values
• Configured and accessed via the PVSS
• Tools exists for mass configuration of archival
settings (smoothing, averaging, etc.)
• All data written into the archive is timestamped
• Only values read from devices are stored in the
archive (e.g. no direct data flow between the
configuration database and the archive)
• Recipe versions are archived if the recipe is
changed
12
31/05/2005
Peter Chochula
What data goes into the DCS
archive?
• Only monitored values marked for archival are
stored (DP config required). This includes:
• Data directly acquired by the DCS – HV, LV,
FERO, magnetic field, environmental
parameters, …
• External Data and Services – electricity, racks,
DSS, LHC information, …
• ALICE specific information – run number, run
type, …
13
31/05/2005
Peter Chochula
The DCS Data Flow
DAQ
TRI
HLT
Electricity
Ventilation
ECS
Config.
DIM, DIP
Cooling
Gas
Magnets
PVSS
Safety
Access Control
LHC
Devices
Devices
Devices
Devices
Archive
14
31/05/2005
Peter Chochula
DCS Archive implementation
• New method of PVSS archiving is finally available
• The PVSS RDB archival is replacing the previous
method based on local files
– All PVSS-based tools are compatible with the new approach (we
can profit from the PVSS trending etc.)
– Oracle database server is required
– Architecture resembles the previous concept based on files
• A set of Windows DLL’s and Linux libraries is used to
access the archive from PVSS
– Data storage and retrieval within the PVSS works without
changes
• A library handles the management of data on the Oracle
Server (create/close tables, backup tables…)
15
31/05/2005
Peter Chochula
PVSS Archive Tables
• For each group of archived values a set of tables is generated
– LastVal – input table storing the most recent value
– Current – a table keeping a history record of measured values.
• An Oracle trigger is used to write data to this table
• The table is closed if it exceeds a predefined size and is replaced with a new
one
• The latest available values are copied to the new table automatically
– Online – a copy of the closed Current table
– Offline – a table written to backup media and not directly available
• A set of internal tables for database maintenance exists
• Archive tables are using their own tablespace (this is why a trigger is
needed)
• For each Datapoint several parameters are stored:
– Value
– Timestamp(s)
– Flags (for example reliability)
16
31/05/2005
Peter Chochula
Basic DCS archive configuration
Offline
SPD
Offline
HistoryValues
SPD 00000011
HistoryValues
00000012
Online
Online SPD
SPDHistoryValues
Current
00000123
HistoryValues
SPD 00000124
HistoryValues
00000125
SPD
LastValValues
(arrays)
Offline
SPD
Offline History
SPD 00000011
History
00000012
Online
SPD
Online History
SPD 00000123
Current History
SPD 00000124
History
00000125
SPD
LastVal
(“basic” datapoints)
17
31/05/2005
Peter Chochula
Accessing the Archive Tables
• A set of libraries is available on the PVSS
side to access the data from the database
• The libraries hide the archival complexity –
user need to specify the Datapoint name
and the time interval
• A dedicated library allows for direct
database access (bypassing the PVSS
managers)
18
31/05/2005
Peter Chochula
Example of Data Selection in PVSS
(1)
19
31/05/2005
Peter Chochula
Example of Data Selection in PVSS
(2)
20
31/05/2005
Peter Chochula
Example of Data Selection in PVSS
(3)
21
31/05/2005
Peter Chochula
Example of Data Selection in PVSS
(4)
Result of the
query
Generated SQL
Statement
22
31/05/2005
Peter Chochula
External access to the PVSS
archive
• Database schema is available – data can
be queried from external programs
• A set of basic Oracle views is provided by
the ETM
– The complexity of the table partitioning is
hidden
• A PVSS HTTP server allows for remote
DP queries
23
31/05/2005
Peter Chochula
Root–to–PVSS interface
• Developed by V.Filimonov (ATLAS)
• Allows for extraction of PVSS data into root
• PVSS manager (GetArc) accepts requests from
clients, reads data from PVSS database and
sends it to the client.
• A set of Root classes define the client protocol
• Manager and Client interact via TCP/IP using
the PVSS API
24
31/05/2005
Peter Chochula
Root–to–PVSS communication
Example: get data for a given period of time
TPVSSAccess *sock = new TPVSSAccess("pcpix06.cern.ch",4242);
char *dp = "TestFloat1.floatvalue";
int rlen = sock->GetTimePeriod(dp,startTime,endTime,len,Values,ts);
DP name
Time Period
values
Length of data
timestamps
Additional classes allow for displaying trends etc.
25
31/05/2005
Peter Chochula
Root–to–PVSS example of trend
Online trend in PVSS
Online trend in Root
26
31/05/2005
Peter Chochula
Condition database developments
• The conditions database will store a subset of
the archived data in a form convenient for offline
processing
• JCOP framework is developing the interface to
conditions database
• Conditions data will be written “on fly” by a
dedicated process
• CMS, ATLAS and LHC-B plan to use COOL so
all common tools will be available only for this
architecture
• No developments for root are foreseen
27
31/05/2005
Peter Chochula
Present Status
• Prototype of the configuration database
exists
• We are running a private Oracle server in
the DCS lab
• First tests with RDB archiving performed,
feedback provided to ETM
• We are aiming for a stable service during
this summer (P2 and Lab)
28