Download IRMIS (Don Dohan)

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Database wikipedia , lookup

Entity–attribute–value model wikipedia , lookup

Clusterpoint wikipedia , lookup

Relational model wikipedia , lookup

Database model wikipedia , lookup

Transcript
IRMIS – Introduction
- IRMIS collaboration meetings: APS,SNS, CLS, FNAL, TRIUMF, SLAC, DESY
- accumulate participant facility data capture requirements and RDB experience
- site specific data capture requirements. Difficult to design a universal schema.
- original attempt at creating an IRMIS_base and IRMIS_extensions unsuccessful
-- deliberate cut-off in coverage
beyond this region
IRMIS - Discussion
- schema
- services
- applications (thin client)
- deployment
- rapid prototyping environment
- PYIRMIS
IRMIS Design: General Guidelines/Goals
- flexible schema design – site neutral. Wide range of users and use
cases  lowest common denominator
- (Minimalist) modeling approach: define and use extensible tables, rather
than extending the schema to manage ‘scope creep’ ( single component
type table, vs component type classification based on behavior or
function).
- Resist the development of site specific or application driven schema
structures.
- Pragmatic approach. Follow RDB standards (database normalization,
etc) where possible unless it adversely affects performance. Maximize
emphasis on problem domain, minimize RDB specialty technology
- Attempt to incorporate business rules as close to the database as
possible (away from the application layer)
IRMIS - General Guidelines (cont’d)
- schema does not rely on any naming convention (either hardware or
software)
- naming conventions (plural) are useful in populating databases, but once
the data is in IRMIS, there is no reliance on the naming convention
IRMIS3
The component hierarchy schema (IRMIS2) was developed at the APS to
manage the complexity of operating a fully constructed facility. In this
situation, the inventory of components are effectively fully installed, resulting in
tight coupling between the installation and inventory.
In response to user requests in the design and construction phase of NSLS21,
the relational database schema has been substantially enhanced –> IRMIS3.
IRMIS requirements continue to evolve, particularly as users begin to use the
database. It is impossible to freeze the schema at this point. A mechanism is
required where intermediate data can be inserted into IRMIS3 for user test and
evaluation, while allowing global schema changes to be made without losing
the user input investment.
A rapid prototyping environment has been developed for IRMIS data modeling
and access to support these evolving user requirements.
1User requests include accelerator physics, controls, electrical engineering, survey and alignment,
magnet measurements, and vacuum.
IRMIS Relational Database Domain Evolution
Schema/Domain
Database Access
Presentation Layer
Epics
Oracle Pl/SQL
Web Browser
perl-dbi
crawler, command line
php
Web Browser
jdbc
IRMIS Desk Top: IDT-pv
jdbc
thick java client (vcct)
jdbc
IDT-component
IRMIS1
IRMIS2
cmpnt hierarchy/
cable
IRMIS2.aps
AOI, IMS, PLC, global php
search tool, spares, …
Web Browser
IRMIS2.1
cmpnt hierarchy,
jdbc
cable2, lattice (phase1)
web applets
install::inventory
model (phase 2)
pv_meta
service config/launch
elog, traveler
Browser (django templates)
HLA thick client (PyQt)
IRMIS3
python
Domain: EPICS
Domain: Install
Domain: Cable
Domain: Inventory
Domain: Component Type
Domain: PV_Meta
Domain: Service Config
Domain: Model (Phase 1)
T-4 Lattice Description: Work in Progress
naming convention
Tracy-4 lattice
Lingyun
parser
Tracy flat file
IRMIS
Official Sharepoint Lattice
Domain: Lattice/Model
(phase 2)
Domain: Elog
Domain: Traveler
Domain:
People/Authorization
IRMIS Development Phases:
- phase 1: user requirements and basic schema design
- phase 2: bulk data entry - pre operation, capture the “asbuilt” configuration
- phase 3: application development
- phase 4: go to phase 1
- this must be done without loss of data and with
minimum impact on existing applications.
Phase 2: Bulk Data Entry. Engineering Spread Sheet Templates
The vast amounts of data to be stored in the IRMIS relational database cannot be
handled with a manual, graphical user interface. Programmatic access to the database
is required.
Domain data specifications for IRMIS3 are defined using engineering spreadsheet
templates*. The spreadsheet templates provide several functions:
A. Mechanism for requirements refinement using an advanced UI technology that
is familiar to the engineering user groups. (Which data, what the data means, and how
the data is related…) The spreadsheet becomes a requirement specification.1
B. Spreadsheet data is imported into IRMIS using Python scripts containing spread
sheet and IRMIS business logic. This allows for easy schema changes and data reimport, without loss of user data entry effort. The spreadsheet becomes a contract.
C. Data ownership issues (eng. group access privilege issues; data integrity). The
spreadsheet become the de-facto master data set. User buy-in.2
D. Leverage off powerful UI features from Excel: (column:row sort/extend,
naming convention macros,…. etc)
1.changes in the template require agreement by both controls and engineering
2.Thomas Russo and Kent Holland from FRIB are working with J.Escallier@BNL on spread sheet template
Spreadsheet Data Entry Scripts – IRMIS3/PyIRMIS
1.Component Types: Create magnet component type definitions from
electrical engineering spreadsheets. 27 magnet component types, 14 power
supply types inserted
2.Component Type Spreadsheet. 29 vacuum component definitions,
diagnostics, injector sheets wip (naming convention issues)
3.Install: Insert magnet, power supply and cable installation data from
electrical engineering spreadsheets
- allows global renaming (installed cmpnt-types, cabling)
- 1734 ring component installation definitions inserted
4.Inventory: Insert magnet measurements from Jain
- measurement for 118 magnets inserted
- traveler data for 45 magnets inserted
5.Pv_meta: Insert pv_meta (using pv naming convention)
- pv_meta for 3493 PVs from VIOC inserted
6.Lattice: Insert lattice from Sharepoint Official File- 2703 lattice elements
entered (including drift spaces)
7.Model: Insert TWISS results from TRACY calculation (Guobao)
- 208 TWISS records entered (1 superperiod)