04 Dec 2001CMS Week - Bonding WGSalvatore Costa - Catania Writing Bonding Data into the CMS Tracker...

04 Dec 2001CMS Week - Bonding WGSalvatore Costa - Catania

Writing Bonding Data into the CMS Tracker Construction Database

Salvatore Costa

University and INFN – Catania

04 Dec 2001CMS Week - Bonding WG 2 Salvatore Costa - Catania

Sample DB Table

INDEX VAR

(integer)

VAR1

(integer)

VAR2

(float)

VAR3

(vector

of int)

VAR4

(vector

of float)

VAR5

(string)

Module

id13 4.7 2 6 10 4.1 5.0 7.3 blah

Module

id25 99.3 7 5 1 0.4 5.3 1.1 foo

Test Struc

id1 … … … … …


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


Preliminary Data List

From:– Alan’s Bonding Procedure doc

(h.home.cern.ch/h/honma/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


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


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


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.”


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 breakFBL = first bond lift-offSBHB= 2nd bond heel breakSBL = 2nd bond lift-offMSB = mid-span breakOTH = others, such as pad lift, cratering


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” TableThe “Bonding” Composite


User Interface

• Constraints to the design

• Software technology

• Interface package

• Access control

• Organizational model


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.


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


Bonding-to-DB GUI Web Page


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).


Organizational Model

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

1. Central

2. Distributed


Central Model

CHANGE/ADD

ENTER

VIEW

CT

Center 1dirs

VALIDATE

Center 2dirs

Center 3dirs

File system in CT dai

ly c

ron

job

Ba

cku

p c

op

y to

diff

ere

nt

dis

kT

ran

sla

tion

to

XM

» U

plo

ad

to

Lyo

n


Distributed Model

CHANGE/ADD

ENTER

VIEW

C1

VALIDATE

Center 1dirs

daily

cro

n jo

b

CHANGE/ADD

ENTER

VIEW

C2

VALIDATE

Center 2dirs

daily

cro

n jo

b

Backup copy to different diskTranslation to XM » Upload to Lyon

Backup copy to different diskTranslation to XM » Upload to Lyon


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

04 Dec 2001CMS Week - Bonding WGSalvatore Costa - Catania Writing Bonding Data into the CMS Tracker...

Documents

Transcript of 04 Dec 2001CMS Week - Bonding WGSalvatore Costa - Catania Writing Bonding Data into the CMS Tracker...