Writing Bonding Data into the CMS Tracker Construction Database

22 Jan 2002Tracker Week - Bonding WGSalvatore Costa - Catania

Writing Bonding Data into the CMS Writing Bonding Data into the CMS Tracker Construction DatabaseTracker Construction Database

Salvatore Costa

University and INFN – Catania

22 Jan 2002Tracker Week - Bonding WG 2 Salvatore Costa - Catania

A Bit of History

• I volunteered to take care of DB entry for the Bonding WG in Nov 2001

• I had an initial proposal ready for the 4 Dec 2001 Meeting but was unable to get to Geneva

• Turned presentation into a Web document whose URL Alan sent to everybody

• Gathered only Alan’s (extensive) comments

I’ll present here an updated proposal that takes into account Alan’s comments


Organization of the Talk

• Unlike what you may have seen in my original proposal’s Web doc, today I’ll first

Describe the software interface for writing Bonding data into DB

• Then

Present the current (proposed) list of data to write into DB


User Interface Architecture

• Design background

• Design motivations

• Software technology

• Interface package

• Access control

• Deployment


Interface Design Background (1)

• The Tracker DataBase WG (Contardo et al.) provides a DataBase environment for permanent storage of Tracker construction Parameters (TrackerDB) in Lyon.

• It is up to individual WGs to:• decide which data to store into TrackerDB• create the relevant Tables• devise a suitable procedure to upload data into TrackerDB

• TrackerDB is meant for retrieval of detector characteristics in the years to come, as well as for information flow between one WG and the next as construction progresses.

• TrackerDB is not meant for storage of temporary or ephemeral pieces of data while some operation is in progress; for this, WGs are encouraged to develop their own intra-WG information flow systems.



• In general, to see data already existing in TrackerDB (e.g. from WGs whose operations occurred before Bonding, such as Sensors) one has to query TrackerDB using an interface provided by the DB WG (called BigBrowser)

• However, I’m investigating if I can provide this functionality from within the interface I’m writing for the Bonding WG.

• TrackerDB already provides for entry of Shipping/Receiving data at Institute level (through BigBrowser).

• This does not apply to shipping/receiving from a given operation at an Institute. Thus individual operations such as Bonding may want to include receiving and shipping info as part of their own data.



• To write Bonding data into TrackerDB, following the Sensor WG, I foresee a 2-step process (motivation on next slide)• 1st step: Bonding Operators write data to a “local” HTML file (local to

the Bonding WG)

• 2nd step: Local HTML files are translated to mandated XML and uploaded into TrackerDB in Lyon.

The 1st step is performed by an easy-to-use Web interface (which triggers sophisticated scripts which run behind the scenes)

The 2nd step is performed by “smart” scripts (i.e. they know when to act) which also run behind the scenes.


Interface Design Motivations

• 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


Software Technology

I propose to adopt a Graphical User Interface which uses the

Electronic equivalent of paper forms:

…linked behind the scenes to…

…which write, update, allow to view…

…and eventually translate & upload them into DB

Such a package must run on Unix machines, but Users can sit in front of any computer with a Web Browser in any part of the world

Web Browser Forms

Perl scripts

“local” HTML 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).


Interface Deployment

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

L »

Up

loa

d t

o L

yon


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


Interface Evolution

• The interface may actually grow more complex,as Alan thinks Pre-Bonding, Bonding and Post-Bonding may be so separated in time and person doing them that it may be wiser to upload their info to TrackerDB separately.

• In this case: 1. Front page will give access to VIEW and CHOOSE OPERATION

(Pre/Bond/Post). 2. For each Operation the previously planned actions will apply

(ENTER/CHANGE/VALIDATE)3. Access control may be via 2 pw’s/center as now, or 6 pw’s/center

(pre op, pre su, bond op, bond su, post op, post su), or just 3 (pre, bond, post) by merging op&su privileges for each operation.


Alternate Interface

VIEW

CT

Center 1dirs

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

L »

Up

loa

d t

o L

yon

CHANGE/ADDENTER

VALIDATE

CHANGE/ADDENTER

VALIDATE

CHANGE/ADDENTER

VALIDATE

Pre

Bond

Post


Software Writing PlanI plan to first• Write the Web-based interface (HTML files and Perl scripts)

that write “local” files (already doing it)Then• Wait for experience to build up and modify interface (and

already wrutten files!) as needed/requestedWhen variables appear stable• Create Tables• Create programs that upload local files to TrackerDB• Upload all at once local files written thus farFrom then on • Upload local files to DB with the scheduled jobs


• Will start after consensus reached on a stable set of variables

• Following general TrackerDB guidelines, will have single tables per “operation”, aggregated into “composites” that might be queried as a whole

Bonding Table Creation

“Pre-Bonding” Table “Bonding” Table

“Post-Bonding” Table “Pull Test” Table

“Bonding Repair” Table(s)The “Bonding Repair” Composite

The “Bonding” Composite


“Pre-Bonding” Table

Description Name Data Type Entry Mode

Bonding Center BOND_CENTER STRING(128) CHOOSE FROM LIST

Pre-bonding operator name

PREBOND_OP STRING(128) CHOOSE FROM LIST

Receiving date& time

(By Pre-Bonding Inspector, not Institute!)

PREBOND_RECV_TIME FLOAT TYPE-IN WITH AUTOMATIC DEFAULT

Status found in pre-bonding inspection

PREBOND_STATUS STRING(384) TYPE-IN

Pre-Bonding quick readout test

PREBOND_QUICK_TEST ??? (Alan) ???

Unpacking PREBOND_UNPACK ??? (Alan) ???

Storage PREBOND_STORAGE ??? (Alan) ???

Shipping date& time

(From Pre-Bonding to Bonding) -AND/OR-

PREBOND_SHIP_TIME FLOAT TYPE-IN WITH AUTOMATIC DEFAULT

Ready-for-Bonding status READY_FOR_BOND STRING(128) TYPE-IN (default: not ready)


“Bonding” Table



Bonding operator name BOND_OP STRING(128) CHOOSE FROM LIST


(By Bonding) (start time?)

BOND_RECV_TIME FLOAT TYPE-IN WITH AUTOMATIC DEFAULT

Bonding machine Manufacturer

BOND_MACH_MFT STRING(128) TYPE-IN

Bonding machine Model BOND_MACH_MOD STRING(128) TYPE-IN WITH AUTOMATIC DEFAULT

Bonding machine ID BOND_MACH_ID ??? (Alan) TYPE-IN WITH AUTOMATIC DEFAULT

Bond tool manufacturer BOND_TOOL_MFT STRING(128) TYPE-IN WITH AUTOMATIC DEFAULT

Bond tool type ID BOND_TOOL_ID ??? (Alan) TYPE-IN WITH AUTOMATIC DEFAULT

# bonds with tool thus far BOND_TOOL_NUM INTEGER TYPE-IN


“Bonding” Table (cont’d)


Wire manufacturer BOND_WIRE_MFT STRING(128) CHOOSE FROM LIST

Wire type BOND_WIRE_TYPE STRING(128) CHOOSE FROM LIST

Wire date of fabrication BOND_WIRE_FAB_DATE FLOAT TYPE-IN

Wire date of first usage BOND_WIRE_FU_DATE FLOAT TYPE-IN

Bond jig # BOND_JIG_NUM INTEGER TYPE-IN WITH AUTOMATIC DEFAULT

Machine-specific parameter set

BOND_PARAM_SET STRING(128) <CENTER>-<MACHINE>

-<LOOKUP TABLE #>

Ambient Temperature BOND_TEMP FLOAT TYPE-IN

Ambient Relative Humidity BOND_REL_HUMI FLOAT TYPE-IN

# repaired failures during bonding

BOND_REPAIRED STRING(384) ??? TYPE-IN

Shipping time (from Bonding (end time?)

PREBOND_SHIP_TIME FLOAT TYPE-IN WITH AUTOMATIC DEFAULT


“Post-Bonding” Table



Post-bonding operator name

POSTBOND_OP STRING(128) CHOOSE FROM LIST


(By Post-Bonding Inspector

POSTBOND_RECVTIME FLOAT TYPE-IN WITH AUTOMATIC DEFAULT

Status found in post-bonding inspection

POSTBOND_STATUS STRING(384) TYPE-IN

Post-Bonding cold test POSTBOND_COLD_TEST ??? (Alan) ???

Post-Bonding fast test POSTBOND_FAST_TEST ??? (Alan) ???

Packing ??? ??? (Alan) ???

Shipping date& time

(From Post-Bonding)

-AND/OR-

POSTBOND_SHIPTIME FLOAT TYPE-IN WITH AUTOMATIC DEFAULT

Ready-for-Testing(???) status

READY_FOR_TEST STRING(384) TYPE-IN (default: not ready)


ND-Pull Test Results

• Done only on Test Structures (true?)Description Name Data Type Entry Mode

Pull tester ID PULL_TEST_ID INTEGER TYPE-IN WITH AUTOMATIC DEFAULT

Number of pulls PULL_N_PULLS INTEGER TYPE-IN

Failed Channels PULL_FAIL_CH VECTOR OF INTEGERS

TYPE-IN

Average Strength PULL_STR_AVG FLOAT TYPE-IN

Strength Sigma PULL_STR_SIGMA FLOAT TYPE-IN

Failure type PULL_FAIL_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

ND

D

Writing Bonding Data into the CMS Tracker Construction Database

Documents

Transcript of Writing Bonding Data into the CMS Tracker Construction Database