280 likes | 297 Views
The DCS Databases. 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. The PVSS Architecture. UI Layer. User Interface Manager.
E N D
The DCS Databases Peter Chochula
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
Peter Chochula The PVSS Architecture UI Layer User Interface Manager User Interface Manager User Interface Manager Application Layer Control Manager API Manager Communication and Storage Layer Data Manager Event Manager Driver Layer Driver Driver Driver
Peter Chochula User Interface Manager User Interface Manager User Interface Manager Control Manager API Manager Data Manager Event Manager Driver Driver Driver In a scattered system, the managers can run on dedicated machines In a simple system all managers run on the same machine
Peter Chochula User Interface Manager User Interface Manager User Interface Manager User Interface Manager User Interface Manager User Interface Manager User Interface Manager User Interface Manager User Interface Manager Control Manager Control Manager Control Manager API Manager API Manager API Manager Distribution Manager Distribution Manager Data Manager Data Manager Data Manager Event Manager Event Manager Event Manager Distribution Manager Driver Driver Driver Driver Driver Driver Driver Driver Driver In a distrubuted system several PVSSII systems (simple or scatered) are interconnected
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
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.
Peter Chochula Example Datapoint System1:TestFloat1:floatvalue Value SystemName:DPName:DPE DPT DP Config Timestamp DPE
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)
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
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)
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
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, …
Peter Chochula Devices Devices Devices Devices The DCS Data Flow DAQ TRI HLT Electricity Ventilation Config. ECS Cooling DIM, DIP Gas PVSS Magnets Safety Access Control LHC Archive
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…)
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)
Peter Chochula Basic DCS archive configuration Offline SPD HistoryValues 00000011 Offline SPD History 00000011 Offline SPD HistoryValues 00000012 Offline SPD History 00000012 Online SPD History 00000123 Online SPD HistoryValues 00000123 Online SPD HistoryValues 00000124 Online SPD History 00000124 Current SPD HistoryValues 00000125 Current SPD History 00000125 SPD LastValValues SPD LastVal (arrays) (“basic” datapoints)
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)
Peter Chochula Example of Data Selection in PVSS (1)
Peter Chochula Example of Data Selection in PVSS (2)
Peter Chochula Example of Data Selection in PVSS (3)
Peter Chochula Example of Data Selection in PVSS (4) Result of the query Generated SQL Statement
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
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
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); Additional classes allow for displaying trends etc. Time Period DP name values timestamps Length of data
Peter Chochula Root–to–PVSS example of trend Online trend in PVSS Online trend in Root
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
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)