# Presentation: 345076

## IRMIS

*RDBCore – integrated s/w, h/w and cable databases*
*D. Dohan, Mar 9, 2005*

## PV ERD – essential elements

**is part of**

**loaded in**

**An EPICS record has a name and is of a specific type.**
**Each record type has a DBD record definition**

**Records have fields, which are name/value pairs.**

**A record instance is defined by its set of field/value pairs.  These instance values are contained in .db files.**
**A record definition may span several .db files**

**Records are loaded into (belong to) an IOC.  (Channel Access does not need to know which IOC the record belongs to, **_**but the developer does**_**)**

**No record-type specific tables – the crawler ‘discovers’ the implemented record types.**

**Schema and crawler site neutral**

## PV Schema

## PV schema

**more of a software system schema – capturing the entire system logic **
- ioc configuration and boot information
- database definitions
- inter IOC links
- CA clients (adl now, alh coming, others..)
- time stamp – like CVS tag
**exhaustive PV list is required ********crawler**
- mining PV info to extract control system hardware components
*~70% of initial APS components ‘discovered’ by PV data mining*
- possible use in name server?

## IRMIS Components

**What is a component?**
- “ a constituent element, as of a system”... (Google)
- unit replaceable physical entity associated with the accelerator
*IO card, chassis, serial link, ..*
- more primitive granularity than a ‘device’
*do not assign a high level physics ‘role’ to a component*
*less subjective – no naming convention issue*
- more on this later
- more geared to how the facility is assembled, rather than how it functions.
**component approach was originally based on EPICS device-types**
- now extended to cover all accelerator equipment
*mechanical components, physical spaces, ac distribution*
*multi-hierarchy*

## Component RDB –essential elements

**is a**

**is controlled by**

**is housed by**

**is****powered**** by**

**At this point, we can begin tabulating all of the components in the accelerator - the table contains component_id/component_type pairs.  **

**In IRMIS, each **_**control**_** component is ****controlled by****, or ****passes data**** ****to**** a unique control parent.  This 1:M relation defines a ****control hierarchy**

**The database table now contains the cmpnt_id, the cmpnt_type and its control_parent_id, which points to another component instance somewhere in the database.**

**The basic entity in the component database is the concept of a component type.**

**Issue: The database contains only the components that an IOC can ‘see’.  Another issue was how to handle the ‘location’ attribute – limited queryability.**

**Any component instance is of a specific type.  Each component is assigned a logical # (the EPICS io addr) and a physical descriptor to distinguish similar hierarchy siblings**

**Component table:**

**An additional hierarchy has been added – the ****power hierarchy****. Any component gets its power feed from a unique power source, which is component in the DB.**

**An additional hierarchy is defined – the housing hierarchy.  Each component is ‘****housed****’ within another component within the DB.  Every device has a housing parent.  The location attribute is replaced by the housing hierarchy. May now add non control components**

| cmpnt_id | cmpnt_type_id | control_p_id | housing_p_id | power_p_id | ln | pd | S/N | etc |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |

- ----------

## Multiple Hierarchies

**attempt to capture orthogonal hierarchical concepts **
- who controls the component?
- where is it located?
- where does the component derive its power?
**more than just another attribute – allows (hierarchy based) querying**
- what other components are controlled by this c-parent?
- what is located in this chassis? what else is nearby?
- what other components are powered by the same circuit?
*concept of ‘path’ provided by the hierarchical topology*
**components need not be members of all 3 hierarchies**
- every component is a member of the housing hierarchy
*it must be located somewhere, even if it is in a stores cabinet*
*every component is stored only once in the database*

## Assembling a (sub) facility

**type**

**id**

**cpid**

**hpid**

**ppid**

**room**

**1**

**-**

**0**

**-**

**1**

**rack**

**2**

**-**

**1**

**-**

**2**

**rack**

**3**

**-**

**1**

**-**

**3**

**circuit**

**5**

**-**

**4**

**4**

**5**

**ac panel**

**4**

**-**

**1**

**0**

**4**

**pwr strip**

**6**

**-**

**2**

**5**

**6**

**chassis**

**7**

**9**

**2**

**8**

**7**

**chas. ps**

**8**

**-**

**7**

**6**

**8**

**cpu**

**9**

**0**

**7**

**7**

**9**

**1014**

**10**

**7**

**7**

**7**

**10**

**gpib dev**

**12**

**11**

**2**

**6**

**12**

**gpib link**

**11**

**10**

**10**

**-**

**11**

**chassis**

**13**

**-**

**3**

**-**

**13**

**1014**

**14**

**-**

**13**

**-**

**14**

**1014D**

**15**

**-**

**13**

**-**

**15**

## Connections vs components

**in the case of the 1014 – only the serial number is changed when swapping spares..**
- the id of the row in the db is not changed – the connection, or system configuration, has not changed
- the software (i.e. the PV) is only aware of the connection, not of the serial number of the module.
- if the 1014 is replaced with a pin compatible module (eg the 1014D above), then both the serial # and the component _type_ changes. The connection id remains the same. The PV does not know the difference.
- The user is never directly aware of the component/connection id.
- each line in the component table (‘relation’ in RDB speak) represents a multi-dimensional abstract connection.  The components making up the connection are merely attributes of the connection

## Detailed Component schema

## Cables

## Cable ERD

**is a**

**is part of**

**is part of**

**is controlled by**

**is housed by**

**is part of**

**is****powered**** by**

**Each component has a set of **_**ports**_**  - (0 or more)**

**To handle the wide variety of cable types, each pin in each port is stored in the database.  The pins accept the individual ‘signals’ carried in the conductors in a multi-strand connector. **

**A cable is something with a connector. Has a color and label.  The cable is what the user handles, ie connects between ports**

**The user connects cables, the database connects pins****. **

**Pins have signals, which will eventually relate to software PVs.**

**With the component database infrastructure in place, the cable database is surprisingly simple.  Most of the complexity is handled in the hierarchical component database.**

**The cable and component schema is site neutral.  There is no APS or SNS signature: there is not even any evidence that we are modelling an accelerator.**

## Detailed cable schema

## Component and Cable Editor/Viewer – wip

## Cables and components – (discussion, future)

**a cable transmits a signal from an output of one component to an input of another component.**
- the cable does not have a signal name – each port does
*the cable has 2 signal names associated with it*
**the component takes its inputs and transforms them into a set of outputs**
- concept of a component as a signal transformer
*eg : light box O = I*
*eg: fan-out Oj = I (j=1,8)*
*allow end-to-end signal tracing (for simple xfmr’s)*
**abstract the notion of component as a signal XFMR, and store in the RDB - this is still not functional decomposition/description****.**
**expanded characterization of signal types – to simplify cable entry**

## Wiring list

## Wiring list

**equipment**

**wiring list/****interface control document**

## Extending component types

**Extend component types to include accelerator equipment**
**put the **_**external component**_** into the component RDB**
- wiring list information is now handled by the cable database
- gives the control engineer a better feel for how the system as a whole is supposed to work
- can be extended to include power supplies
*high current power feeds are generalized signals*
*power supply ‘transforms’ the drive signal to high current*
- storage of this abstract transformation within the RDB
- more abstract: can be extended to include magnets
*I/P signal is high current, output signal is B-field (abstract)*
- more abstract – extension to the beam as a component
*I/P signal = B, output signal = X,Y,etc BPM signal. Perhaps not, but this is what the modelers in essence do.*
- can also be extended (downward) to replaceable board level components – fpga, etc

## Components vs devices (and naming conventions)

**PS controller**

**Magnet**

**Power Supply**

**Beam**

**Suppose that all the component transforms are stored in the database – would this be a basis around which to model physics data, at the same time providing the engineer with the component/assembly description?**

**This schema is still site-neutral – only the system assembly data (the configuration instance data) is site specific. Functional modeling replaced by component transfer functions.**

**Now that all the components are in the database, what about another hierarchy****  - the physics device hierarchy?**

## RDBCore - Work in Progress

**is a**

**is part of**

**is part of**

**is controlled by**

**is housed by**

**is part of**

**is part of**

**loaded in**

**is****powered**** by**

## IRMIS Future (cont’d)

**IRMIS as a core (site-neutral) RDB schema and basic applications – only 28 tables are in RDBCore at present.**
**RDB Extensions:**
- How can local site specific extensions be built to be (at least partially) reusable? (e.g. framework approach)
- Example – ioc applications based on the component DB
**Universal component type table – at least for the EPICS supported devices.  Locally extensible**