Status of Hardware Database development

Description:

Whenever a hardware component is changed, the table FABCOMPONENT gets a new entry which tells which device was updated. The type of this device is determined by a number referring to a row in the table FABDEVICETYPE. The device is further specified by the (optional) variables serial_num, model and manufacturer. The revision_num keeps track of how often a specific device was involved in a change. The changes to a device and its location in the detector are listed in a separate table, FAB_"DEVICE_TYPE"_LOC. There is a different table for each device type. The MID points back to the SEQNO of the FABCOMPONENT table. The reasons for inserting or removing this device are given by an int which points to motid the table FABMOTIVATION. There is also room to give comments to these changes. However, when a component is taken out of the detector, like being send somewhere for repair, it will be listed in the FABOUTOFSERVICE table instead. Also in this table the MID refers to the SEQNO in FABCOMPONENT. The where_id points to where_id from the table FABWHERE and tells where the device is.

Releases:

To get the latest version of the tables, follow the directions on how to prime MINOS database tables and use the file fab_XXXX.lis.

Release v1.0 has been put into the offline database at FNAL.

• latest version: v1.0
• version 0.4: v0.4
• version 0.3: v0.3
• version 0.2: v0.2
• version 0.1: v0.1

Open Issues:

Solved (+-) Issues:

• Redesigning FAB_"DEVICE_TYPE"_LOC and FABOUTOFSERVICE? See email discussions.
  It has been agreed to get the system working before adding more complicated features.
• Is there a need for a allowed mask for the out-of-service location? Or are we going to trust on the sanity of the person filling this table?
  General consensus: this is difficult to implement and probably not needed
• separate tables for near detector? Or shall we try to unify?
  
  These tables should be able to accommodate hardware changes for both detectors, since the associated vld table gives info about which detector one is dealing with.
• device_type: is the enum type flexible, i.e. can it be changed after the table has been created? Or does one need to define all possible types at creation time?
  The list of devices are now in a separate table, so that it can be *easily* expanded as needed.
• location: it is not clear to me what the type should be. I guess it will be an int of a certain length, depending on the type of device?
  It consists of a number of columns and depends on the device type. See also at the links under the Monday, June 21, 2004 discussion.
• allowed_mask: The question whether the type size can be made large enough to accommodate all possible combinations. A possible solution to this problem is just removing this column from this table and leave the checking of the possible motivations up to the front end program. Although this makes the front end program dynamic, which is probably a feature we do not want.
  In the current design, I have adopted the approach proposed by Nick:
  If we want to stay with a data-driven system we could use a string instead consisting of say colon delimited substrings. For each substring we could have the format:-

  LOC (for location) | OUT (for out of service) - device type (where * = all)

  So if a motivation is available for all devices either for a location change or an out of service entry, the mask would be change or an out of service entry, the mask would be

  :LOC-*:OUT-*:

  If a mask is only suitable for a crate location change, the mask would be:

  :LOC-CRATE:

  If we wanted we could even have exception rules:-

  :LOC-*:LOC-!CRATE:LOC:!PMT: i.e. valid for all location entries unless it is a CRATE or a PMT.
  Efficiency of parsing this mask isn't an issue, it's only used when building drop down menus when servicing glacially slow human input.

Design:

---

Mark Dierckxsens (mdier@bnl.gov)

Last modified: Tue Feb 14 14:12:21 2006