What Do I Want from an RDB?

1. What Do I Want from an RDB? Ned Arnold, APS March 9, 2005

2. What do I want? • To alleviate the guilt when someone mentions “documentation of the installed control system”. • “As-built drawings” • To allow for quick, yet well-documented changes. • e.g. “We need a thermocouple on the septum magnet for the next machine studies … tomorrow” • To allow for quick, yet well-documented changes by a <competent> substitute staff member. • e.g. “… and George isn’t here today!” • To provide convenient & thorough information for fast troubleshooting [i.e. helpful documentation] • To provide convenient and thorough information to “on-call” staff for systems for which they are unfamiliar. • “I can’t talk to the Attenuator in Sector 7” • “There is a white box on my medm screen”

3. What do I want? • To make the learning curve of applications less steep • To automate finding the root cause of a communication problem • To run numerous “integrity crawlers” for constant monitoring of the health of the control system (self generating?) • To alleviate the guilt when someone mentions “documentation of the installed control system”.

4. What doesn’t work? • Maintaining accurate information on the thousands (~15,000+) of installed devices and hundreds of independent applications is not manageable with a “Revision Controlled Drawing” approach. • Our control system is not static. • There are many “soft” entities that defy drawings. • Different “views” of the system are needed at different times, yielding redundant drawings. • Drawings cannot be “queried”.

5. Drawings are not maintainable <with our budget>

6. What might work? What do we want to document? • All PV definitions in all the IOC’s • Provides an aggregate collection of the entire “distributed database” Process Variables

7. What might work? What do we want to document? • All active IOC’s • IP # • Contact Person • Ethernet Connections • Boot path • etc, etc, etc IOC’s (CAS’s)

8. What might work? What do we want to document? • All installed components • VME /VXI Modules • Instruments • Racks • etc, etc, etc Components

9. What might work? What do we want to document? Cables • All installed cables • Ambitious, but necessary

10. What might work? What do we want to document? • Installed ‘Applications’ • A <somewhat arbitrary> collection of functions (databases, seq programs, etc.) that can be identified as a unique “application”: • LINAC Beam Position Monitors • Bunch Compressor Scraper • Storage Ring Injection Kicker PS Control • SR Vacuum Valve Interlocks

11. What might work? What do we want to document? Cables Must document all of these installed entities … and … Components IOC’s (CAS’s) Process Variables

12. What might work? What do we want to document? • and their relationships to one another • Components are related to other components by • how they communicate control information • how they are housed • how they are powered • Applications are related to PVs, Components, etc • IOCs are related to Components, PVs, Applications • Cables are related to Components (via ports)

13. All entities are inter-related … • Given a Cable, one can determine: • Device, IOC • PV • Applications • Given a IOC, one can determine: • Applications • Devices • Cables • PVs • Given a PV, one can determine: • Applications • Devices, IOC • Cables

14. What can it tell me? • What process variables are associated with this device? • What process variables were added, changed, or removed since the last run? • Where does the other end of this cable go? • What components do all of these non-functioning devices have in common? • Which module type in this system has the worst reliability history? • How many devices of a particular model number are installed? • Where are all the devices of a particular model number installed? • What application software will be affected if this device is removed? • What equipment will be affected when this breaker is locked-out?

15. What do I get? • No guilt when someone mentions “documentation of the installed control system”. • Quick, yet well-documented changes. • Quick, yet well-documented changes by a <competent> substitute staff member. • Convenient & thorough information for fast troubleshooting [helpful documentation] • Convenient and thorough information to “on-call” staff for systems for which they are unfamiliar. • “This PV isn’t working” • “I can’t talk to the Attenuator in Sector 7” • “There is a white box on my medm screen”

16. Benefits of a relational database approach • Utilizing relational database technology and defining connections between the entities yields the benefits of extensive querying capabilities through the tables of data. • Immediate tracing of a fault to the root cause • Predicting what applications will break when a module is removed • Locating every instance of a particular device • Convenient and expedient [ i.e. really cool ] tools encourage wide participation in keeping the data current

17. Three Relationships of Components: Control/Housing/Power

18. How do we get there? • Two approaches • Descriptive (describes what is installed) • Prescriptive (defines what is to be installed) • An exhaustive prescriptive solution has not been accomplished (as far as we know) • We think an exhaustive descriptive solution is within reach • Having an exhaustive descriptive solution may alleviate some difficult requirements on a prescriptive solution (e.g. history) • An exhaustive descriptive solution and a partial prescriptive solution may certainly co-exist. • Question: Are an exhaustive descriptive solution and an exhaustive prescriptive solution redundant? • If yes, not until someone succeeds • If no, then we all ought to do the easy one first

19. How do we get there? • We feel that everyone can benefit from an exhaustive descriptive approach and that it is complementary to the prescriptive efforts being undertaken.

20. What do I want? • An identification of those areas where there is the most overlap of needs. • An intense collaboration to fulfill those needs in a way that can be extended to accommodate site specific requirements. • If we can leverage enough resources, we feel that it is entirely possible to deliver an exhaustive descriptive approach (that can be used at any EPICS site) by the end of 2005. • This does not obviate the need for prescriptive solutions. In fact, it might make them easier.