# Presentation: 354144

## RDB for Controls Configuration Management: Complications

- Roland Müller

**Base****d on/ ****Update**** of previous Presentations given**** by**
- B. Franksen: EPICS Meeting `01, SLS/PSI
- T. Birke: ICALEPCS `01, San Jose
- S. Hunt: IADBG (Int. Accel. DB Group) `01, San Jose

## Synopsis, Update + Introduction to next Talk New Problems Encountered

## Goal: DB Based Configuration Maintenance

- Add/Delete Devices in DB
- Procedures and Scripts propagate Changes to Configuration Files
- Consistency Guaranteed

## Initial BESSY Database SystemDevice Oriented

- Magnets

**magnet name**

- Power Supplies

- m:n

## Worked Sufficiently Well forCreation of RTDB

- Standard mechanismpower supplies, vacuum system, RF PLC-interface, triggers/timings, ...

*Many instances (substitutions)**of few different types (templates)*

**Notes:**
Device I/O
Functionality + logic in RTDB-template
DB + template -> RTDB
PS: channel-structure in template, RF: channel-structure in DB

## Initial / Current StateDatabase System

- Configuration/parameters are stored and retrievedby device or device class(power supply, magnet, rf, vacuum pump...)
- Every class has it’s own set of tables/views...
- Devicename is bootstrap
**<DEVICE>:<channel>.<ATTR>**but **<channel>** and **<ATTR>** are not in DB!Experience:
- Device oriented model is Unmaintainable:
-     Additional knowledge is needed in every DB client to deduce the full channel name

**Notes:**
Frontend computer (IOC) needs runtime database configured
Clients (display manager, alarm handler, archiver...) need configuration

## New DB Structure DevelopedBasic Elements

- Name
- The central repository of device-names (naming convention)
- Gadget
- A specific device or a group (class, family) of devices/groups
- Tree-like structure (leafs are actual devices)
- Higher level nodes provide grouping/abstraction
- Every gadget has a unique *name*
- Signal
- The building block of which devices are composed
- Tree-like structure (leafs are actual signals/records)
- Roughly corresponds to RTDB template
- Usually contains one – or few tightly interacting – record(s)
- e.g. “an analog readback from a CAN-bus I/O-card”

**Notes:**
The tree-like structure is actually a directed acyclic graph where any path between two nodes has to be unique

## New DB Structure Developed Basic Elements

- Attribute
- Each signal can have a number of attributes
- Each attribute is related to exactly one signal
- An attribute of one signal can be “translated” into one or more attributes of a child signal
- Record
- Instantiates an entity, that can be filled with values
- Connects gadgets with signals
- Completely automated table (insert/delete)
- Process Variable (PV)
- The actual configuration values
- Connects an attribute with a record and may assign a value

## Example (simplified)

- Gadgets

**Notes:**
PS-1..3	actual instances of power supplies
MK-1,2	different brands of power supplies (with different properties)
PS		power supplies as an abstract class

Quad, Sext	logical families of power supplies based on what magnets are connected
Optics		abstract class

## Example (simplified)

**<GADGET>****:****<signal>****.****<ATTR>**
**PS****:****rdbk****.****MUX       ******** ****2****PS-1****:****rdbk****.****MUX     ******** ****3****PS****:****simple****.****EGU     ******** ****“A”**** ****MK-2****:****simple****.****MAX-I ******** ****350**** ****PS-3****:****Uout****.****PREC    ******** ****5****Quad****:****alpha****.****VAL    ******** ****4.7538**

**Uout**

**short**

**xtend**

**set**

**on**

**stat**

**rdbk**

**simple**

**off**

**Notes:**
Connect the gadgets to the appropriate signals
Ex:
	1. Default for an attribute for all PS
	2. Override 1. For a specific PS
	3. Abstract default for all PS
	4. Abstract value to be translated into specific attributes (DRVH, HOPR...)
	5. Specific value for sub-class
	5. (signal not shown) ex. For non-I/O-parameter but parameter important for high-level-apps

## New Structural Overview

## Project Status as of Nov `01

- Tables and general structure are implemented
- No real data (except names) in those tables yet
- Views, frontends and generic scripts still missing
- Next steps
- Test system with a new application
- Develop necessary frontends and scripts in parallel
- The plan is, to develop generic web browser frontends and standalone command line scripts

*Topic of Next Talk*

## New Problems need Solution

- Even our Guineapig `Power Supply ́is hard to model
- High Multiplicity / Relative Simplicity should be easy
- Well developed Configuration Management:
- DB Templates
- Generic dm2k Screens
- CDEV ddl Files, Alarms, Save/Restore ...
- Unsolved Problems Remain:
- Problem 1: Complex Devices are set up of Standard Powersupplies (Inheritance)
- Problem 2: Multiple Entries to a Single Physical Device added (Main + Higher Order Input)

## Partially Known Problems: Polymorphic DevicesGenome Analysis of Names

## Composite Device 

## Higher Order Inputs

## Summary

- On One Side DB Model, DB Content, Views and Tools should replace the existing Device Oriented System
- On the other End a clear Vision of Generalized Configuration Requirements for all Generic Applications is no more available
-  Manpower and Time would help a lot