Writing%20Bonding%20Data%20into%20the%20CMS%20Tracker%20Construction%20Database

1
Writing Bonding Data into the CMS Tracker
Construction Database

• Salvatore Costa
• University and INFN Catania

2
Sample DB Table
INDEX VAR (integer) VAR1 (integer) VAR2 (float) VAR3 (vector of int) VAR4 (vector of float) VAR5 (string)
Module id1 3 4.7 2 6 10 4.1 5.0 7.3 blah
Module id2 5 99.3 7 5 1 0.4 5.3 1.1 foo
Test Struc id1
3
Bonding-to-DB Tasks

• Define list of data to write
• Initial proposal (now)
• Feedback from centers (by end of next week)
• Form consensus
• Create Bonding Tables in the DB
• Setup User Interface
• Choose software technology (done)
• Create interface package (in progress)
• Implement suitable access control (in progress)
• Deploy according to an organizational model

4
Preliminary Data List

• From
• Alans Bonding Procedure doc (h.home.cern.ch/h/ho
  nma/www/Bonding/bondingproc011104.pdf)
• Witnessing a simulated bonding operation
• An exchange of messages between me and Alan
• Broken into
• Data common for all centers
• Data that may be machine (center) dependent
• Pull test results

5
Common Data
Description Name Data Type Entry Mode
Bonding Center BOND_CENTER STRING(128) CHOOSE FROM LIST
Pre-bonding operator name PRE_BOND-OP STRING(128) CHOOSE FROM LIST
Pre-bonding (data entry) date time PRE_BON_TIME FLOAT AUTOMATICALLY FROM SYSTEM
Status found in pre-bonding inspection PRE_BOND_STATUS STRING(384) TYPE-IN
Post-Bonding operator name POST_BOND_OP STRING(128) CHOOSE FROM LIST
Post-Bonding (data entry) date time POST_BOND_TIME FLOAT AUTOMATICALLY FROM SYSTEM
Status found in post- bonding inspection POST_BOND_STATUS STRING(384) TYPE-IN
Channels not bonded NON_BOND_CH VECTOR OF INT TYPE-IN
Recommended repairs BOND_REPAIRS STRING(384) TYPE-IN
6
Machine-Dependent Data
Description Name Data Type Entry Mode
Air pressure AIR_PRESSURE FLOAT TYPE-IN
Loop mode, height, pull up, pull over, pull down, pull off LOOP MODE, HEIGHT, PULL UP ,PULL OVER, PULL DOWN, PULL OFF INTEGER(S) TYPE-IN
Z speed Z_SPEED INTEGER TYPE-IN
Test height TEST_HEIGHT INTEGER TYPE-IN
Search Speed (1st, 2nd) SEARCH SPEED_1, _2 INTEGER(S) TYPE-IN
Bond Force(at both ends) BOND_FORCE_1, _2 INTEGER(S) TYPE-IN
Bond Time (at both ends) BOND_TIME_1, _2 INTEGER(S) TYPE-IN
Bond Ultra Sound (at both ends) BOND_U_S_1, _2 INTEGER(S) TYPE-IN
7
Machine-Dependent Param.

• Let me quote Alan
• I would suggest that each center decide what
  machine parameters are worth recording and either
  come to you with a request for center-dependent
  data base entries or make their own DB.
• In the case of a center that does a variety of
  different bonding jobs (like CERN), it may be
  necessary to have the list of machine parameters
  for CMS module bonding to be part of their
  procedure (checklist) so that the operator can
  verify that the machine is set up correctly for
  bonding CMS modules.

8
ND-Pull Test Results

• Done only on Test Structures
• Do we want to record these in DB at all?
• If we do

Description Name Data Type Entry Mode
Number of pulls N_PULLS INTEGER TYPE-IN
Failed Channels FAIL_PULL_CH VECTOR OF INTEGERS TYPE-IN
Failure type FAIL_PULL_TYPE VECTOR OF STRINGS(?) CHOOSE FROM LIST

• List of possible values
• FBHB first bond heel break
• FBL first bond lift-off
• SBHB 2nd bond heel break
• SBL 2nd bond lift-off
• MSB mid-span break
• OTH others, such as pad lift, cratering

9
Bonding Table Creation

• Not done yet
• Will start after consensus reached on a
  (preliminary) set of variables to write
• DB Group (Contardo et al.) do not create Tables.
  They provide GUI to create Tables and rules to
  comply with about their formal structure
• Their general guideline to WGs is to create a
  single table per operation and aggregate them
  into a composite that might be queried as a
  whole
• ?

Pre-Bonding Table Post-Bonding Table
Machine Parameters Table Pull Test Table
The Bonding Composite
10
User Interface

• Constraints to the design
• Software technology
• Interface package
• Access control
• Organizational model

11
Interface Design Constraints

• Unlike other WG operations, Bonding does not
  produce automatically any computerized data
• All data must be entered
  manually
• The bonding operation (on a given module) may
  occur in different installments, carried-out by
  different operators
• Data first entered may undergo changes as the
  operation (on the same module!) progresses
• Example non bonded
  channels
• Database WG strongly discourage frequent
  insertion of tiny bits of data, let alone data
  that hold valid for only brief periods of time.
• They want users to gather
  meaningful blocks of
• (reasonably) stable data before
  uploading them to DB.

12
Software Technology

• I propose to adopt a Graphical User Interface
  which uses the Electronic equivalent of paper
  forms
• linked to
• which write, update, and eventually upload into
  DB
• Such a package must run on Unix machines

Web Browser Forms
Perl scripts
local files
13
Bonding-to-DB GUI Web Page
14
Access control

• Why
• Interface is on a URL world accessible
• How
• No control on the front page or to VIEW bonding
  data
• OPERATOR password to ENTER or CHANGE/ADD data
• SUPERVISOR password to VALIDATE a module for
  permanent recording into DB
• Both Passwords different for each center 2 x
  Ncenters
• Passwords decided by center Responsible Persons,
  communicated to me, installed by me.
• At each center, it will be the responsibility of
  the center Responsible to reveal either password
  to the appropriate person(s).

15
Organizational Model

• The whole interface package can be deployed
  and maintained in 2 different ways, corresponding
  to 2 different organizational models for its
  maintenance
• Central
• Distributed

16
Central Model
VIEW
Center 1 dirs
ENTER
Backup copy to different disk Translation to XM
Upload to Lyon
Center 2 dirs
CT
CHANGE/ADD
Center 3 dirs
VALIDATE
daily cron job
File system in CT
17
Distributed Model
VIEW
Backup copy to different disk Translation to XM
Upload to Lyon
ENTER
Center 1 dirs
C1
daily cron job
CHANGE/ADD
VALIDATE
VIEW
Backup copy to different disk Translation to XM
Upload to Lyon
ENTER
Center 2 dirs
C2
daily cron job
CHANGE/ADD
VALIDATE
18
Model Comparison

• Central
• Pros
• Easier for me to deploy
• Easy for me to maintain by just broadcasting any
  changes to all centers
• Cons
• System unusable by all if CT goes down(one could
  use a printed form for a couple o days

• Distributed
• Cons
• Deployment requires interaction between me
  local sys admins and local configuration
• Maintenance requires local expertise and will
  lead to different setups among centers
• Pros
• Failure only affects single center at the time