1 / 20

What Do I Want from an RDB?

What Do I Want from an RDB?. Ned Arnold, APS March 9, 2005. 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.

Download Presentation

What Do I Want from an RDB?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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.

More Related