# Presentation: 354161

## BESSY Configuration ManagementPlans / Wishes

- Thomas Birke, Benjamin Franksen, Bernhard Kuner,
- Ralph Lange, Patrick Laux, Roland Müller,
- Götz Pfeiffer, Joachim Rahn
- Experiences with our old system
- Its deficiencies
- Lessons learned
- Requirements for a new system

**Notes:**
Developed since ~’95
Realized insufficiencies in ~’99
Started thinking about a new structure in 2000
Several talks about that in Switzerland ’00, San Jose ’01, Berlin ’02 and Santa Fe ‘04

## Experiences with our old system

- Device oriented approach
- Set of RDB-tables and at least one application per device class
- 100s of tables in 10s of different structures
- not maintainable (after a few years)
- Tight coupling of application and RDB is hindering,
- several iterations with DB-admin in the beginning
- Data-maintenance by device-expert is nice – *but never really worked** *
*Most* parameters for *most* devices are in RDB
- Cross-application links (ALH, Archiver, Save/Restore...) require central structure or are also unmanageable

**Notes:**
~350 tables and ~200 views
Maintenance done using plain SQL by DB-admin and/or controls-staff
Small application developed completely without RDB!
Worked quite well for development and commissioning

## Information from e.g. capfast-drawings is missing in RDB!
DEVICE:substructure:signal.ATTR
	for most applications, just the device-name is in the RDB

What about version control and fallbacks?
Source-code is in CVS but RDB-contents?The older versions of an application may not even work with the newer RDB-contents!
Use ORACLE features?DBMS_FLASHBACK.ENABLE_AT_TIME('2005-02-28 10:00')

**DEVICE****:****substructure****:****signal****.****ATTR**
- 	for most applications, just the device-name is in the RDB
- What about version control and fallbacks?
- Source-code is in CVS but RDB-contents?The older versions of an application may not even work with the newer RDB-contents!
- Use ORACLE features?**DBMS_FLASHBACK.ENABLE_AT_TIME('2005-02-28 10:00')**

**Experiences with our old system**

**RDB**

**Notes:**
~350 tables and ~200 views
Maintenance done using plain SQL by DB-admin and/or controls-staff
Small application developed completely without RDB!
Worked quite well for development and commissioning

## More deficiencies

- No way to map hierarchies
- Devices may consist of several sub-devices
- A setpoint of a power supply may be the sum of several *independent* values (higher order inputs)
- Some devices / device-classes are not in RDB at all
- No “*need”*/time to create appropriate RDB structures
- Information necessary to configure generic tools (ALH, Archiver...) is wide-spread or not even existing
*those tools are configured manually!*
- Set of tables per device-class
- uncontrolled growth of RDB
- RDB gets more and more unmanageable
- We found insufficiencies in our naming convention ***(side-show)*****                ****DEVICE****:****substructure****:****signal****.****ATTR**

- covered

- uncovered

**Notes:**
No way to configure all tools from out of RDB
Complex devices are set up using standard power supplies
Maintenance jobs are often “just done once” – every once in a while

## It’s quite comfortable (in some aspects)
Allows us to use convenient external tools like capfast, vdct, CVS, my-favourite-editor, scripts... to create databases, substitution-files, template-files or other configuration files
Device-oriented approach has some advantages in maintenance
E.g. a broken power supply gets replaced by one of a different type  requires change of one entry in RDB

Generic tools that access PVs directly (ALH, Archiver, Save/Restore ...) are mostly configured by hand

Higher level tools (orbit-correction ...) access devices via cdev and hence are sufficiently supported (except...)
cdev-classes (for high-level-apps) map directly to device-classes (but also need information from other source!)
But parts of the cdev-ddl file are configured by hand as well

- Allows us to use convenient external tools like capfast, vdct, CVS, my-favourite-editor, scripts... to create databases, substitution-files, template-files or other configuration files
- Device-oriented approach has some advantages in maintenance
- E.g. a broken power supply gets replaced by one of a different type  requires change of *one* entry in RDB
- Generic tools that access PVs directly (ALH, Archiver, Save/Restore ...) are mostly configured by hand
- Higher level tools (orbit-correction ...) access devices via cdev and hence are *sufficiently* supported (except...)
- cdev-classes (for high-level-apps) map directly to device-classes (but also need information from other source!)
- But parts of the cdev-ddl file are configured by hand as well

**Nevertheless, it’s not that bad...**

## What we require a new system to support

- Generation of
- *.db, *.substitution, *.template
- All other kinds of configuration dataALH, Archiver, Save/Restore, Orbit-Correction,other yet unknown applications...
- Different *views* to the same dataset

**RDB**

- *

- *

- *

- *

- *

- *

## What we require ... (contd.)

- Lose coupling between RDB and Application (ASCII-Files)
- Experiment with application without changing RDB-contents
- Develop an application without RDB and *then* import configuration data
- CVS-control
- May cause problems with information that is shared between applications (local copies!)

- Application

- generic standardand specialized scripts/programs

- script/program*(may not be necessary)*

*all under CVS control*

**RD****B**

-  ASCII-Files

- Capfast, vdct...

## What else ...

- Continue to use external tools to create configuration data
- Capfast, vdct, emacs...
- primary source of information may not be in RDB
- One common generic RDB-structure for all applications
- Every type of configuration information goes into this generic RDB structure
- Application specific frontends for maintenance
- web-based, Java, whatever...
- Scripts to import and export application-specific configuration data
- EPICS-DB, Archiver, ALH...
- Version-Control, Logging
_*What*_ did _*who*_ change _*when*_ (and maybe even _*why*_)?
- CVS of the results gives hints, but may not be enough
- Application-specific access control
- All users/applications use one table!

## What else ... (contd.)

- Development of a new Application must be possible without requiring the DB-admin or anybody else to create new RDB-structures
- Generic tools for basic tasks
- A simple application should not need to provide fancy SQL-statements or scripts/programs written in whatever language to create its configuration data
- Im-/export of standard configuration data
- db/template/substitution/bpt, ALH, Archiver...
- Arbitrary hierarchies of name/value pairs with inheritance, overloading, typing, tagging...
- Object-oriented data model
- Classes with inheritance, overloading, types, tags
- Complex applications define their own classes
- Base functionality stored in base classes
- Have all existing PVs available in RDB (upfront!)
- Storage for other user-data *(maybe not a must-have...)*
- part-/serial-numbers, repair/maintenance history...

## There may be more ...

- ... but that’s basically it.

## What we already did

- Developed a generic RDB-model
- Represents a directed acyclic graphwith name/value pairs attached to nodes
- 4 tables and a few views
**gadget**				–	nodes in graph
**gadget_relation**		–	edges in graph
**gadget_type**		–	arbitrary grouping/tagging
**attribute**			–	name/value pairs
- Access-functions (API) implemented in PL/SQL
- e.g. access *gadgets* by *path* with wildcards**/ArchiverConfig/ctl/HF/PAH1R/pCavRdbk****/ArchiverConfig/ctl/HF/PAH_R/pCavRdbk****/ArchiverConfig/%%/pCavRdbk**
- 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
- First tests with sample applications
- Had to “improve” quality of SQL-statements because of degrading performance

## DB Structure

| gadget |  |
| --- | --- |
| PK | gadget_key |
|  | name |

| gadget_relation |  |
| --- | --- |
| FK1FK2FK3 | parentchilddistancetype |

| gadget_type |  |
| --- | --- |
| FK1FK2 | gadgettype |

| gadget_attribute |  |
| --- | --- |
| FK1FK2 | gadgetnamevalue |

## Gadgets Example

- A

- B

- C1

- C2

| Key | Name |
| --- | --- |
| 1 | A |
| 2 | B |
| 3 | C1 |
| 4 | C2 |

| Parent | Child | Distance |
| --- | --- | --- |
| 1 | 2 | 1 |
| 2 | 3 | 1 |
| 1 | 3 | 2 |
| 2 | 4 | 1 |
| 1 | 4 | 2 |

**gadget**

**gadget_relation**

## Sample Graph

- ArchiverConfig

- ctl

- HF

- Lifetime

- PowerSupplies

- ...

- ...

- ...

- PAH1R

- ...

- ...

- PAH2R

- pCavRdbk

- ...

- ...

| monitor | 1 |
| --- | --- |
| period | 1 |

| write_period | 30 |
| --- | --- |
| buffer_reserve | 3 |
| file_size | 500 |
| ... |  |

- ApplicationConfig-FileGroupPV-Name

## Sample Graph

- PAH1R

- PAH2R

- pCavRdbk

- ...

| HOPR | 650 |
| --- | --- |
| LOPR | 0 |
| ... | ... |

| CAN-timeout | 500 |
| --- | --- |
| ... |  |

- EPICS-DB

- RF-System

- IOC1S15G

- ...

- ...

- ...

- ApplicationDevice-classIOC-namePV-Name

| CANPORT | 2 |
| --- | --- |
| NODEID | 12 |
| ... | ... |