Ralph Lange – EPICS Collaboration Meeting at SLAC, April 2005

A New Attempt to Make Life Easier
Forced by the progress on BESSY’s Willy-Wien-Laboratory project
(compact 200-600 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?

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 …
Script
Text Editor
RDB
The only source of knowledge is experience.

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.

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
IOC
EPICS DB
*
*
CDEV ddl
Measurement
Orbit-Corr.
*
*
High
Level
Applications
RDB
Archiver
AlarmHandler
Save/Restore StripTool
Preconfigured Applications
Screens (adl)
*
Navigation
Displays generic Appl.
* Actually configured from RDB
Imagination is more important than knowledge.

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.

…
CAN-timeout
…
500
CANPORT
NODEID
…
…
2
12
…
…
…
HOPR
LOPR
…
650
0
…
I used to go away for weeks in a state of confusion.

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.

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?