1. RDB-Based Configuration Management - A New Approach
Ralph Lange – EPICS Collaboration Meeting at SLAC, April 2005

2. RDB-Based Configuration Management – Reinventing the Wheel?
A New Attempt to Make Life Easier
Forced by the progress on BESSY’s Willy-Wien-Laboratory project (compact MeV synchrotron for the German bureau of standards currently under construction at the BESSY site)
Discussed and developed by Thomas Birke, Benjamin Franksen, Bernhard Kuner, Ralph Lange, Patrick Laux, Roland Müller, Götz Pfeiffer, Joachim Rahn
A question that sometimes drives me hazy: am I or are the others crazy?

3. RDB Use for BESSY‘s Current Control System
Device oriented approach:
One set of RDB tables and at least one application per device class
Devices are represented by a set of DB templates:
Simple templates are edited as plain text, complex templates are managed by CapFast, vdct
Substitution files are generated from RDB data by a script in the application directory:
Many applications use simple generic scripts, some contain many exceptions
Other applications (ALH, Archiver, Snapshots, …) are configured manually in most cases
Text Editor
CapFast, vdct …
DB Template
Substitutions
EPICS DB
Script
RDB
The only source of knowledge is experience.

4. The Top 5 Features That We Don’t Like
100s of tables in 10s of different structures
Not maintainable after a few years
Tight coupling of application and RDB
Several iterations with RDB manager (requiring a few days) when starting a new application
Data maintenance by device experts is nice
But never worked
Most parameters for most devices are in the RDB
For some singular devices creating the RDB structures would be just too much effort
We never had a complete view of our system
Links to other applications (ALH, Archiver, Snapshots, …) are not within the RDB
Wildly growing, distributed and unmanageable
All internal information from complex template files is missing
For complex templates, there’s only one device entry in the database
No way to map hierarchies
Devices may consist of sub-devices
A set point may be the sum of independent values (higher order inputs)
Our naming convention is not sufficiently covering the sub-device part
A person who never made a mistake never tried anything new.

5. What We Would Expect From a New System
Generation of configurations for all kinds of applications
.substitution, .template, .db
AlarmHandler, Archiver, Snapshots, Orbit Correction, StripTool, … even unknown future applications
All these are different views to the same data set
EPICS DB
CDEV ddl
RDB
Save/Restore
Archiver
AlarmHandler
StripTool
generic Appl.
Screens (adl)
Orbit-Corr.
Measurement
High Level Applications
Navigation Displays
IOC
Preconfigured Applications *
Actually configured from RDB
Imagination is more important than knowledge.

6. A New Attempt Generic RDB model
Stores hierarchies allowing “is part of” and “is of type” relationships
Represented by directed acyclic graphs with name/value pairs attached to any of the nodes
Implemented in 4 tables and a few views
RDB structures have no installation and application dependencies
Access functions (API) in PL/SQL to be run on the RDB server side
27 functions/procedures with 60 signatures (~1500 LOC)
All write access and most reads go through API
Interfaces with all scripting languages used at BESSY
Values may contain math and string expressions referencing other names
Generic tools to handle the graphs and name/value pairs
Graphical application to manipulate the graphs
Insanity: doing the same thing over and over again and expecting different results.

7. … PAH1R PAH2R pCavRdbk EPICS-DB RF-System IOC1S15G
Sample Graph
PAH1R
PAH2R
pCavRdbk …
LOPR
650
HOPR
500
CAN-timeout
EPICS-DB
RF-System
IOC1S15G
Application Device Class IOC Name PV Name 12
NODEID 2
CANPORT
I used to go away for weeks in a state of confusion.

8. How Far We Got Database Structures finished Basic PL/SQL Functions
implemented, stable, being tested
Generic Graphical Tool
under development
Sample Application
Test environment is EPICS DB generation – so this works
Waiting for the first real world application (this summer) – that naturally won’t work
A man should look for what is, and not for what he thinks should be.

9. To Sum It Up
Driving force: The need to create applications more efficiently
Generic RDB structure to represent hierarchies: The hierarchy information, which used to be contained in the specific database structure, is now moved to being data in a generic structure Query results are sets of name/value pairs (allowing redefinition and expressions along the hierarchy)
Implementation is well under way
Tests show promising results, first real applications later this year: We’ll keep you posted on the experiences…
If we knew what it was we were doing, it would not be called research, would it?