Daniel Lellouch (Cern/Weizmann Institute)1 TGC Stock and Production Data Base u Do you have already...

Daniel Lellouch (Cern/Weizmann Institute)

1

TGC Stock and Production Data BaseTGC Stock and Production Data Base

Do you have already a fully organized bookkeeping? Almost fully operational, running in Are you happy with it? Ask the customer! But home made and flexible What are your needs in the various areas ? Parts quantities and logics, assembly history, QC By whom data are entered into your bookkeeping system? Two levels: manager & operator Who is the responsible in your group to maintain the documentation and the integrity of

your bookkeeping? I How do you identify parts? Code= Full Type + Serial Number (whenever needed) What software utilities do you use in your bookkeeping system? Java + Cloudscape

What are your ideas on what the ATLAS central database should contain, and how your

system database will be interfaced? Driving question: what do we need this for? My guess: centrally keep only what is

relevant for on-offline (I.e. QC) Once this is established, interfacing ( i.e extracting & exporting info in the requested

format ) is `just’ a technicality To 1st approximation: for the TGC system, NO info is needed for on/offline Only extracted info: assembly progress for PPT (Project Progress Tracking)


2

TGC’s in a few words TGC’s in a few words (relevant to our business)(relevant to our business)

Basic object: a Thin Gap Chamber Basic production unit: A `unit’ ( i.e. a chamber doublet or triplet sandwich) 3600 chambers corresponding to 1584 units to be produced in two sites:

Weizmann Institute in Rehovoth, Israel (1104 units, 2544 chambers) KEK in Tsukuba, Japan (480 units, 1056 chambers)

Parts are centrally produced in either place (grosso modo mechanics in IL, electronics in JP) Units are of human dimension : maximum height is 2.30m (basket ball player), maximum

weight is 200kg (Sumo fighter) 11 major Unit types (external dimensions) but internal wire ganging, L/R symmetries, holes

for alignment corridors, … make it to ~180 different chamber types to build; all units of the same major type are built in a unique place (either Japan or Israel)

Number of parts not so big: ca. 150 per unit. Main concerns

Ensure perfect information flow from initial design to simulation, technical drawings, production line,...

Minimize mistakes due to numerous parts of exactly same external dimensions but crucially different internal details


3

Master info source: Excel spreadsheetMaster info source: Excel spreadsheet

Keeps all physical, electronic, operational, cost, …. static parameters Info is then exported to :

AMDB (Atlas Muon Data Base) used by Muonbox -> Dice, … Mechanics drawing office ( by hand for the first two `major types’ for which technical

drawing has been produced so far, automatically in the future [parametrised AutoCad] ) Integrated suite of JAVA programs which

produces some of the technical drawings beyond human capability controls the production database runs the production line

Interface program to PPT (Project Progress Tracking)


4


5


6


7


8

Choice of S/W : Java + Cloudscape Choice of S/W : Java + Cloudscape

My personal experience when starting the project: basically FORTRAN + a simple database software (FileMaker) which i used in order to run the scientific secretariat of the EPS/HEP97 conference.

Complexity of apparatus triggered the need for OO programming to describe geometry, detector degeneracy, etc …

Confess that I was fed-up of systems a la FileMaker, which are extremely efficient as long as you are doing something standard but quickly become painful when you are trying to perform unusual operations, and that I was too lazy to look deeply into Access to see whether all functionalities were there.

Market survey led us to go for Java/Cloudscape which looked Cheap (0 + $ 600) and fun Simple for a beginner Powerful: store classes, not only numbers Suitable for distributed computation “Easy” to migrate to something else should Cloudscape, Inc… go bankrupt (!) since it is just an implementation of

standard JAVA interfaces


9


10


11

Distributed environmentDistributed environment

The system consists of One server running the Cloudscape server

program (bought Java code) One PC running the Human Interface for the site

manager (user written Java code) Several PCs (typically one in each room of the

production building) running the Human Interface for the operators. Bar Code readers are connected in parallel with keyboards

Data Base can be accessed for inspection from “anywhere” in the world (provided one knows how to bypass firewalls!…)

Eventually to be duplicated in Japan when fully debugged in Israel and ready to start production over there; no “cross-talk” between databases since:

8 out of 11 major ‘types’ are entirely built in Israel and 3 in Japan Parts are produced/bought/machined in a unique place

JDBC

Manager

Operator Operator Operator


12


13


14

BarcodesBarcodes

Driving principle: enforce barcodes ONLY for what is absolutely necessary; no need to read barcodes when geometry of parts prevents wrong assembly! name should be `self explanatory’ (at least to site manager) serial numbers are need only for large size finished assembled objects

Example of assembly table: U01B1H Multiplicity :8 Made of: D01B3H D01B2H D01B1H D01B3H Multiplicity: 8 Made of :H01B3H K01B3H Tools : PP011 H01B3H Multiplicity: 8 Stocks :SH01B3H Tools :J013

Example of valid barcodes: U08B1I-001.8 U08B1I-002.9 U08B1I-003.0 U08B1I-004.1

Checksum is handled `by hand’ If sticker is unreadable, just type in to keyboard


15


16


17


18

Daniel Lellouch (Cern/Weizmann Institute)1 TGC Stock and Production Data Base u Do you have already...

Documents

Transcript of Daniel Lellouch (Cern/Weizmann Institute)1 TGC Stock and Production Data Base u Do you have already...