The IRMIS Object Model and Services API

1
The IRMIS Object Model and Services API

• C. Saunders, D.A. Dohan, N.D. Arnold
• APS, Argonne National Laboratory, Argonne, IL, USA

The submitted manuscript has been created by the
University of Chicago as Operator of Argonne
National Laboratory (Argonne) under Contract
No. W-31-109-ENG-38 with the U.S. Department of
Energy. The U.S. Government retains for itself,
and others act-ing on its behalf, a paid-up,
nonexclusive, irrevocable worldwide license in
said article to reproduce, prepare derivative
works, dis-tribute copies to the public, and
perform pub-licly and display publicly, by or on
behalf of the Government.
2
IRMIS

• Integrated Relational Model of Installed Systems
• Relational database and applications to
  comprehensively document an EPICS control system.
• 3 main areas documented
• PV (process variables)
• Components (control and accelerator system
  hardware)
• Cables (and conductors)
• Describe, not prescribe
• IRMIS is not a design tool. It documents an
  as-built system.
• Decoupled from EPICS IOC development process.

3
IRMIS

• Designed to answer typical operations and
  maintenance questions
• What PVs are associated with this component?
• What PVs were added, changed, or removed since
  last run?
• Where does the other end of this cable go?
• What components will be affected if we lock out
  this circuit breaker?
• What do all these nonfunctional components have
  in common?
• Which IOC controls the GPIB instrument in this
  rack?

4
IRMIS Getting Data In

• How is data entered into IRMIS?
• Some automated
• Some manual

PV Crawler

5
IRMIS Getting Data Out
PV Viewer
Component Type Viewer
IOC Viewer
Component Viewer
PHP Pages
Cable Viewer
Direct SQL Queries
6
An Implementation Challenge

• 40 database tables, many foreign keys
• Complex database transactions
• Complex user interface use cases
• Database vendor independence
• Application platform independence
• Site independent (work for any EPICS
  installation)
• Extensible (accommodate site-specific extensions)

7
Design Choices

• Business logic in application services layer, not
  in stored procedures/triggers
• Allows for database vendor independence
• Java Swing applications
• Allows for complex user interaction and
  application platform independence
• Hibernate Object Relational Modeling (ORM)
• Elegantly manages gap between object-oriented
  data model and relational data model
• Supports almost every known database vendor

8
Software Layers
Java Swing Applications (built using XAL app
framework)
Display/Edit object graph
Provides operations on object graph
IRMIS Transactional Services Layer
Provides object graph retrieve and save operations
Data Access Objects (DAO) Layer
Object Model
XML mappings
Hibernate Session
JDBC
9
PV Object Model and Services

• Services
• List findRecordList(PVSearchParameters
  searchParams)
• List findCompleteRecordBootHistory(Record record)
• List findReferringFieldsForRecord(List
  iocBootList, Record record)

10
Component Object Model and Services

• Services
• ComponentType findComponentTypeByName(String
  name)
• List findComponentsByType(ComponentType type)
• void saveComponent(Component component)

11
PV Viewer and IOC Viewer
12
PV Viewer in History Mode
13
Component Type Viewer/Editor
14
Component Viewer/Editor
15
Component Viewer/Editor