# Presentation: 345080

## Towards a Universal Component Schema

*IRMIS/Relational Database Workshop *
*Argonne National Laboratory*
*D. Dohan, June 12, 2006*

## Device Databases

***Device Databases***

**Most accelerators have an established ‘device’ database, often representing a significant investment.**
**These ‘device’ schema(s) are typically designed and implemented from an accelerator physics perspective:**
- this influences the naming convention.  *(What about an ‘operations’ perspective/naming convention? a control system engineer perspective?)*
- devices are typically abstracted* according to the overall facility goal (light source, heavy ion collider, etc), and thus take on a site specific signature.
- the site specific nature of each device description/abstraction leads to difficulties in re-use in other facilities
**Traditionally, there has been difficult to re-use/extend existing RDB **

## IRMIS approach

***IRMIS approach***

**Minimize the abstraction/modeling in the definition of ‘components’**
**Thus, instead of assigning a ‘behavior’ to a magnet (“sextupole corrector in the LEBT”), in IRMIS a magnet is simply a component that converts an DC electric current into a magnetic field.  (*****It is characterized by the number of ports it has, rather than what it does to the beam.)***
**The goal is to have component definitions that are universal in nature.**
**"Make everything as simple as possible, but not simpler."**

## IRMIS Components

**What is a component?**
- “ a constituent element, as of a system”... (Google)
- components are obtained by successively partitioning the system/facility until you reach:
*unit replaceable physical entities associated with the accelerator*
- IO card, chassis, serial link, rack, ...
*these (COTS) components are the same building blocks used in building any facility*
- components have a 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

## IRMIS Component Types

**is a **

**A component is of a particular component type.  The component type attributes shown are of a totally general nature (no site specific attributes).  There is no ‘role’ assigned to component instances.**
**There is no component sub-typing in the schema.  A single table describes all component types (> 800 types are required to build and assemble the APS!).**

**Notes:**
No component instance data has been inserted yet.

## Component Connections

** ****Listing component instances is of limited use.**
** ****The IRMIS schema relates components by how they are interconnected:**
** ****physically (housing hierarchy)**
** ****logically (control hierarhy)**
** ****power grid (power hierarchy)**
** ****Each relationship type is hierarchical in nature (each child has a unique parent in each hierarchy).  The hierarchies are modeled as node/edge graphs (DAGs).**
** **

**is a **

**component_rel_type**

- rel_name

**Notes:**
No component instance data has been inserted yet.

## Cables

## Ports and Cables

**is a **

**Notes:**
No component instance data has been inserted yet.