IRMIS – Introduction IRMIS collaboration meetings: APS,SNS, CLS, FNAL, TRIUMF, SLAC, DESY

1. 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

3. IRMIS - Discussion • schema • services • applications (thin client) • deployment • rapid prototyping environment • PYIRMIS

4. 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)

5. 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

6. 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.

7. IRMIS Relational Database Domain Evolution IRMIS1 IRMIS2 IRMIS2.aps IRMIS2.1 IRMIS3

8. service config logscore traveler people/authorization pv_meta elog inventory model (phase2) component type definitions, rules installation/cable EPICS

9. Domain: EPICS

10. Domain: Install

11. Domain: Cable

12. Domain: Inventory

13. Domain: Component Type

14. Domain: PV_Meta

15. Domain: Service Config

16. Domain: Model (Phase 1)

17. T-4 Lattice Description: Work in Progress Tracy-4 lattice Tracy flat file naming convention Lingyun parser IRMIS Official Sharepoint Lattice

18. Domain: Lattice/Model (phase 2)

19. Domain: Elog

20. Domain: Traveler

21. Domain: People/Authorization

22. IRMIS Development Phases: - phase 1: user requirements and basic schema design - phase 2: bulk data entry - pre operation, capture the “as-built” 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.

23. 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 re-import, 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) • changes in the template require agreement by both controls and engineering • Thomas Russo and Kent Holland from FRIB are working with J.Escallier@BNL on spread sheet template

24. Spreadsheet Data Entry Scripts – IRMIS3/PyIRMIS • Component Types: Create magnet component type definitions from electrical engineering spreadsheets. 27 magnet component types, 14 power supply types inserted • Component Type Spreadsheet. 29 vacuum component definitions, diagnostics, injector sheets wip (naming convention issues) • 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 • Inventory: Insert magnet measurements from Jain • measurement for 118 magnets inserted • traveler data for 45 magnets inserted • Pv_meta: Insert pv_meta (using pv naming convention) • pv_meta for 3493 PVs from VIOC inserted • Lattice: Insert lattice from Sharepoint Official File- 2703 lattice elements entered (including drift spaces) • Model: Insert TWISS results from TRACY calculation (Guobao) • - 208 TWISS records entered (1 superperiod)