Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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)