# Presentation: 096018

## IRMIS: Workshop Summary

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

## IRMIS/RDB Workshop

**Workshop on relational databases in EPICS control systems in general, with focus/emphasis on IRMIS.**
**General awareness/acceptance/demand for RDB technology in EPICS control systems has increased dramatically in the recent past.**
**~ 40-50 attendees, huge increase since the kickoff meeting, 2005.**
**IRMIS now installed/being used/modified in a number of laboratories, including:**
- SNS
- SLAC
- APS
- BESSY
- TRIUMF
- CLS

## IRMIS - Introduction

**I****ntegrated ****R****elational ****M****odel of ****I****nstalled ****S****ystems**
- ‘connection-based’ approach to modeling the accelerator and its control system
*integrated ‘system’ coverage of software, hardware and cabling*
**Collaborative approach**
- Goal is to provide re-useable relational database and application frameworks .
- Inter-laboratory approach strengthens the underlying database and application structures.
- The ‘EPICS’ model is used throughout – sophisticated high level tools are developed, but the user always maintains the ability to look ‘under the hood’
- Site-neutral (and RDBMS agnostic).
- Minimalist approach, locally extensible.

**Notes:**
The morning session dedicated to software. 

## PV Schema

** ****PV crawler populates RDB (off-line) from ioc st.cmd information (emulate ioc load process)**
** ****insists on a certain discipline in ioc s/w organization**
** ****full (cross-IOC, soft IOC) coverage. Allows viewing system-wide control system logic, fully macro expanded.**
** ****time stamp - the crawler provides a snapshot of the entire set of operational EPICS databases and their database definitions each time an IOC reboots.**
** ****channel access clients (more on this later)**
** ****no type-specific code or schema structures**
** ****the crawler ‘discovers’ new record types from the installed EPICS database - no code/schema changes**
** ****invites sending IRMIS query sets to VDCT  < nonIOC centric > to analyze inter-IOC logic.  **

**Notes:**
VDCT - non iocCentric approach
-will see example of this is done

## Philosophy 

**Integrate IRMISBase data with SNS data**
**Use the XAL framework whose look and feel most SNS users are familiar with**
**Simple RDB interaction through POJOs and database views to adapt IRMIS to SNS**
**Tailor functions to SNS users**
**But make UI configurable for anyone**

- [Your Presentation Title]

## Map Links

- [Your Presentation Title]

**Notes:**
displays the expanded, fully instantiated macro substituted database definition
shows the immediate EPICS logic surrounding the selected PV. 
very visual demonstration of invalid pvs

## Probe multiple PV’s

- [Your Presentation Title]

## Export to .db file

- [Your Presentation Title]

## ROCS: Sources of Data

**Data are stored in RDB **
**SNS Oracle database**
**Ways to add data to SNS RDB:**
**IRMIS Crawler **
**JERI (online editable reports system)**
**Single task crawler type programs**
**Online editable reports (ROCS)**
**XAL Framework**
**Spreadsheets loaded by SSLoader.java**
**Manual loads and updates**

- [Your Presentation Title]

## Example 1: IOC Configuration Details

**Purpose: **
**Provide IOC configuration information in fast to access and easy to analyze form**
**Data source:**
**Startup.cmd, bootline, st, iocInfo files, db and dbd files**
**Saving data to Oracle:**
**IRMIS crawler**
_**[http://ics-web1.sns.ornl.gov:1982/reports2](http://ics-web1.sns.ornl.gov:1982/reports2)**_

- cmd, db, dbd files

- SNS RDB (Oracle)

- ROCS: IOC Configuration Details report at Control Systems website

- IRMIS Crawler

- IRMIS RDB

- [Your Presentation Title]

## Example 2: IOC Alarm Logs

**Purpose: **
**provide alarm info in such a form that is easy to access and convenient to analyze**
**Data source:**
**The latest alarm log files from EPICS alh**
**Saving data to Oracle:**
**FromAlarmLogToOracle.java **

- The latest alarm log files from EPICS alh

- SNS Oracle DB

- ROCS: IOC Alarm Log report at Control Systems website

- Crawler type java program

- FromAlarmLogToOracle.java

- [Your Presentation Title]

## How to define an AOI...     ...Let’s start with LINAC RF Switching Control System example

- How do we store all this information in an AOI database?

**Notes:**
AOI: An Application of Interest is any set of code (source code, databases, sequence programs, configuration files, displays) that performs a function requested by a customer

## Example AOI Marked Up st.cmd File

- # Absorber  Databases
- #dbLoadRecords ("vpApp/absDb/H2O-xx-FlowPres.db", "SECTOR=05, NODE=18")
- #dbLoadRecords ("vpApp/absDb/H2O-xx-FlowPres.db", "SECTOR=06, NODE=20")
- #<aoi aoi_name="aoi_sr_absorber_water_s5">
- dbLoadRecords ("vpApp/absDb/DL250stat.db","name=S05:H20:PLC,addr=L1 N20 P1 S1")
- dbLoadRecords ("vpApp/absDb/PlcVersionInfo.db","name=S5VP:H20:PLC,addr=L1 N20 P1 S1")
- dbLoadRecords ("vpApp/absDb/H2O-xx-FlowPresOdd.db","SECTOR=05,addr=L1 N20 P1 S1")
- dbLoadRecords ("vpApp/absDb/H2O-xx-FlowPresEven.db","SECTOR=06,addr=L1 N20 P1 S1")
- dbLoadRecords ("vpApp/absDb/H2O-SECTOR-PW-SH-Temp.db", "SECTOR=06")
- #</aoi>
- dbLoadRecords ("vpApp/facilitiesDb/Ambient-SECTOR-Temp.db", "SECTOR=05, NODE=18")
- dbLoadRecords ("vpApp/facilitiesDb/Ambient-SECTOR-Temp.db", "SECTOR=06, NODE=20")

## AOI Viewer

## PV Clients:SLAC Workshop 2005 summary (excerpt)

**Work breakdown – CA client crawlers**
- adl,alh – Janet Anderson, APS
- SDDS – APS
- EDL – J. Sinclair
- SNC – R. Chestnut
- CA archiver – SLAC
- Channel Watcher – M. Zelazny
- BURT s/r – T. Birke
- CDEV – T. Birke
- XAL – J.Patton
- CA Security – APS

## What was done and why

- Modified pv_crawler.pl in a modular manner.
- Didn’t write a secondary crawler.
- Needed to traverse boot tree to see current snapshot.
- Needed to look into seq.o files and do macro substitution
- Requirements for DB viewing
- For a given pv, which sequences use it and on which ioc’s.
- For a given ioc, which pv are used in sequences.
- For a given sequence.o file, what pv’s are used.

## Source files delivered

- src/crawlers/pv/pv_crawler.pl
- Added SEQ logic to main loop
-   src/crawlers/pv/PVCrawlerParser.pm
- Two new subroutines
-   src/crawlers/pv/SEQCrawlerDBLayer.pm
-  New module.
-  src/crawlers/pv/README_SEQ
- src/crawlers/pv/README_SEQ_USE_CASES

## IRMIS @ SLAC Summary

**PV part of the schema only so far**
**Running:**
- PV Crawler since late 2005
- SEQ crawler
- ALH crawler
**Use PV Viewer and batch reporting**
**Plans for client config data and UI**

## IRMIS Uses so far

**PV Viewer for ad hoc database queries**
**PV Crawler reports EPICS database and template errors  (-:**
**Data source for EPICS PV names for SLAC legacy control system **
- formerly dbLoadTemplate and dbReport on hardcoded lists of template files

**Notes:**
(sometimes find myself in the position of adapting an existing epics application for another project – pile of database and template files someone else wrote, layers of indirection and macro substitutions...) IRMIS is great for finding PV source files – which template file produces this PV or set of PVs?
find PV info – which IOC boots PV x?  What record type is PV x?  What are the forward links from PV y?  What are all the PVs in the PEPII project with VAC in the name? 

legacy control system: previously we were using scripts that would do dbLoadTemplate on hardcoded lists of template files to dump to ascii.  Hard to keep up-to-date.  If template added, needed to be added to scripts too...impossible!

## View Child Equipments

**Notes:**
If we select a crate and you can view all the child equipments with in that.
pv-parser - device - archive configuration - crate 
e.g. Crate 
       ..IOC
       ..IP carrierß
       ....IP Module
       ....IP Module
       ..Transition card
      etc.

## CIDB is...

**A database-based application that**
- Enables us to track the control system hardware (stock, installations)
- Embeds the working practices related to controls hardware distribution and maintenance (transparency)
- Tries to make our (controls group HW&SW, system developers, other related groups) lives easier
- It is limited to the hardware handling, but is able to provide configuration information (installation hierarchy)
**Note: I am not a database expert; I will not show any table diagrams or other details in this talk. However, details can be obtained from the developers if wanted.**

## System view

- System contents (VME crate)
- -nonhierarchical installations are also supported

- Request part:
- -select part type from a list
- -add count & date needed

## Status & future

**Core functions**
- In use since February
- CIDB has already much improved our view of the status, and enabled to share and distribute the work better
**Integrate hardware testing**
- Work in progress
**Include purchasing information**
- Important for ordering, repairs, budgeting, etc.
- In progress, planned by end of June
**New applications/modules**
- (diagnostics) component calibration management
**Connection to / integration with IRMIS?**
- The functionality is largely complementary

## Components: IRMIS approach

***Components: 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 a 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."**

## Component Connections

**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:**
Component type - Has been poplulated with most of the EPICS supported devices.  

## Ports and Cables

**is a **

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

## IRMIS Out of the Box

- Database Access
- DDL (SQL scripts for creating IRMIS schema)
*MySQL*
*Oracle*
- Java database access layer (POJO – DAO – Hibernate)
- Perl database access layer (minor extension of Perl-DBI)
- PHP database access layer (simple OO layer on top of PHP-mysql)
- Perl Crawlers
*PV (and SEQ)*
*ADL*
*ALH*
*IOCSR*
*SDDS*
*Network (switch connectivity)*

## IRMIS Out of the Box

- Applications
- IDT – IRMIS DeskTop
*Java/Swing application containing*
- idt::ioc, idt::pv, idt::component, idt::component-type, idt::cable, idt::admin
*Java WebStart support provided*
- Demo PHP PV Viewer
- Demo CFW Java application

## Slide 29

## Slide 30

**Notes:**
Entire hardware configuration on the desktop
Many kinds of queries - demoed by Ned

## One Relationship still escapes us ... PV-to-Signal

- Which field signal does this Process Variable control?

- Which PV(s) monitors this field signal?

- For ongoing operation and maintenance of a large accelerator facility, it is imperative to know the relationship between Process Variables and field signals. This relationship should be traceable in either direction.

## Can this relationship be “discovered” in EPICS?

- Records (PVs) specify the “device type” through the configurable field DTYP.  Additional “device specific” info is identified in INP/OUT fields.

- Although certain specifics about the field signal location can be heuristically determined, *there are no hard rules for mapping between INP/OUT and an actual device port.  Due to the diverse styles of device support authorship, the PV-to-signal relationship cannot be traced with existing EPICS facilities*.

## The Cloud

## Dispersing the Cloud

- The *missing link* to allow fully automatic discovery of the relationship between a Process Variable and a field signal occurs at the device support layer (unique code for each device type).
- If an additional lookup table (link_rule table) were available that identified the relationship between the INP/OUT specifiers and the device port (or parameter), the relationship could be “mined” by an intelligent “crawler” script.  Such a table would look similar to the one below:

## IRMIS - future

- signal tracing
- concept of the component as a ‘signal transformer’
- fault diagnosis
- trace failed PV to the suspect component/port
- locate failed component control path item
- integration with VDCT
- ‘prescriptive’ applications - ioc configuration, etc.
- integration with CSS
- long wish list