22 Jan 2002Tracker Week - Bonding WGSalvatore Costa - Catania Writing Bonding Data into the CMS Tracker Construction Database Salvatore Costa University and INFN – Catania

22 Jan 2002Tracker Week - Bonding WG2 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

22 Jan 2002Tracker Week - Bonding WG3 Salvatore Costa - Catania 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

22 Jan 2002Tracker Week - Bonding WG4 Salvatore Costa - Catania User Interface Architecture Design background Design motivations Software technology Interface package Access control Deployment

22 Jan 2002Tracker Week - Bonding WG5 Salvatore Costa - Catania 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.

22 Jan 2002Tracker Week - Bonding WG6 Salvatore Costa - Catania Interface Design Background (2) 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.

22 Jan 2002Tracker Week - Bonding WG7 Salvatore Costa - Catania Interface Design Background (3) To write Bonding data into TrackerDB, following the Sensor WG, I foresee a 2-step process (motivation on next slide) 1 st step: Bonding Operators write data to a “local” HTML file (local to the Bonding WG) 2 nd step: Local HTML files are translated to mandated XML and uploaded into TrackerDB in Lyon.  The 1 st step is performed by an easy-to-use Web interface (which triggers sophisticated scripts which run behind the scenes)  The 2 nd step is performed by “smart” scripts (i.e. they know when to act) which also run behind the scenes.

22 Jan 2002Tracker Week - Bonding WG8 Salvatore Costa - Catania 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

22 Jan 2002Tracker Week - Bonding WG9 Salvatore Costa - Catania 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

22 Jan 2002Tracker Week - Bonding WG10 Salvatore Costa - Catania Bonding-to-DB GUI Web Page

22 Jan 2002Tracker Week - Bonding WG11 Salvatore Costa - Catania 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 N centers : –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).

22 Jan 2002Tracker Week - Bonding WG12 Salvatore Costa - Catania 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

22 Jan 2002Tracker Week - Bonding WG13 Salvatore Costa - Catania Central Model CHANGE/ADD ENTER VIEW CT Center 1 dirs VALIDATE Center 2 dirs Center 3 dirs File system in CT daily cron job Backup copy to different disk Translation to XML » Upload to Lyon

22 Jan 2002Tracker Week - Bonding WG14 Salvatore Costa - Catania Distributed Model CHANGE/ADD ENTER VIEW C1 VALIDATE Center 1 dirs daily cron job CHANGE/ADD ENTER VIEW C2 VALIDATE Center 2 dirs daily cron job Backup copy to different disk Translation to XM » Upload to Lyon Backup copy to different disk Translation to XM » Upload to Lyon

22 Jan 2002Tracker Week - Bonding WG15 Salvatore Costa - Catania 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

22 Jan 2002Tracker Week - Bonding WG16 Salvatore Costa - Catania 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.

22 Jan 2002Tracker Week - Bonding WG17 Salvatore Costa - Catania Alternate Interface VIEW CT Center 1 dirs Center 2 dirs Center 3 dirs File system in CT daily cron job Backup copy to different disk Translation to XML » Upload to Lyon CHANGE/ADD ENTER VALIDATE CHANGE/ADD ENTER VALIDATE CHANGE/ADD ENTER VALIDATE Pre Bond Post

22 Jan 2002Tracker Week - Bonding WG18 Salvatore Costa - Catania Software Writing Plan I 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/requested When variables appear stable Create Tables Create programs that upload local files to TrackerDB Upload all at once local files written thus far From then on Upload local files to DB with the scheduled jobs

22 Jan 2002Tracker Week - Bonding WG19 Salvatore Costa - Catania 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

22 Jan 2002Tracker Week - Bonding WG20 Salvatore Costa - Catania “Pre-Bonding” Table DescriptionNameData TypeEntry Mode Bonding CenterBOND_CENTERSTRING(128)CHOOSE FROM LIST Pre-bonding operator name PREBOND_OPSTRING(128)CHOOSE FROM LIST Receiving date& time (By Pre-Bonding Inspector, not Institute!) PREBOND_RECV_TIMEFLOATTYPE-IN WITH AUTOMATIC DEFAULT Status found in pre- bonding inspection PREBOND_STATUSSTRING(384)TYPE-IN Pre-Bonding quick readout test PREBOND_QUICK_TEST??? (Alan)??? UnpackingPREBOND_UNPACK??? (Alan)??? StoragePREBOND_STORAGE??? (Alan)??? Shipping date& time (From Pre-Bonding to Bonding) -AND/OR- PREBOND_SHIP_TIMEFLOATTYPE-IN WITH AUTOMATIC DEFAULT Ready-for-Bonding statusREADY_FOR_BONDSTRING(128)TYPE-IN (default: not ready)

22 Jan 2002Tracker Week - Bonding WG21 Salvatore Costa - Catania “Bonding” Table DescriptionNameData TypeEntry Mode Bonding CenterBOND_CENTERSTRING(128)CHOOSE FROM LIST Bonding operator nameBOND_OPSTRING(128)CHOOSE FROM LIST Receiving date& time (By Bonding) (start time?) BOND_RECV_TIMEFLOATTYPE-IN WITH AUTOMATIC DEFAULT Bonding machine Manufacturer BOND_MACH_MFTSTRING(128)TYPE-IN Bonding machine ModelBOND_MACH_MODSTRING(128)TYPE-IN WITH AUTOMATIC DEFAULT Bonding machine IDBOND_MACH_ID??? (Alan)TYPE-IN WITH AUTOMATIC DEFAULT Bond tool manufacturerBOND_TOOL_MFTSTRING(128)TYPE-IN WITH AUTOMATIC DEFAULT Bond tool type IDBOND_TOOL_ID??? (Alan)TYPE-IN WITH AUTOMATIC DEFAULT # bonds with tool thus farBOND_TOOL_NUMINTEGERTYPE-IN

22 Jan 2002Tracker Week - Bonding WG22 Salvatore Costa - Catania “Bonding” Table (cont’d) DescriptionNameData TypeEntry Mode Wire manufacturerBOND_WIRE_MFTSTRING(128)CHOOSE FROM LIST Wire typeBOND_WIRE_TYPESTRING(128)CHOOSE FROM LIST Wire date of fabricationBOND_WIRE_FAB_DATEFLOATTYPE-IN Wire date of first usageBOND_WIRE_FU_DATEFLOATTYPE-IN Bond jig #BOND_JIG_NUMINTEGERTYPE-IN WITH AUTOMATIC DEFAULT Machine-specific parameter set BOND_PARAM_SETSTRING(128) - Ambient TemperatureBOND_TEMPFLOATTYPE-IN Ambient Relative HumidityBOND_REL_HUMIFLOATTYPE-IN # repaired failures during bonding BOND_REPAIREDSTRING(384) ???TYPE-IN Shipping time (from Bonding (end time?) PREBOND_SHIP_TIMEFLOATTYPE-IN WITH AUTOMATIC DEFAULT

22 Jan 2002Tracker Week - Bonding WG23 Salvatore Costa - Catania “Post-Bonding” Table DescriptionNameData TypeEntry Mode Bonding CenterBOND_CENTERSTRING(128)CHOOSE FROM LIST Post-bonding operator name POSTBOND_OPSTRING(128)CHOOSE FROM LIST Receiving date& time (By Post-Bonding Inspector POSTBOND_RECVTIMEFLOATTYPE-IN WITH AUTOMATIC DEFAULT Status found in post- bonding inspection POSTBOND_STATUSSTRING(384)TYPE-IN Post-Bonding cold testPOSTBOND_COLD_TEST??? (Alan)??? Post-Bonding fast testPOSTBOND_FAST_TEST??? (Alan)??? Packing?????? (Alan)??? Shipping date& time (From Post-Bonding) -AND/OR- POSTBOND_SHIPTIMEFLOATTYPE-IN WITH AUTOMATIC DEFAULT Ready-for-Testing(???) status READY_FOR_TESTSTRING(384)TYPE-IN (default: not ready)

22 Jan 2002Tracker Week - Bonding WG24 Salvatore Costa - Catania ND-Pull Test Results Done only on Test Structures (true?) DescriptionNameData TypeEntry Mode Pull tester IDPULL_TEST_IDINTEGERTYPE-IN WITH AUTOMATIC DEFAULT Number of pullsPULL_N_PULLSINTEGERTYPE-IN Failed ChannelsPULL_FAIL_CHVECTOR OF INTEGERS TYPE-IN Average StrengthPULL_STR_AVGFLOATTYPE-IN Strength SigmaPULL_STR_SIGMAFLOATTYPE-IN Failure typePULL_FAIL_TYPEVECTOR 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 ND D