Download
1 / 18
180 likes | 243 Views
TGC 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
E N D
TGC 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) Daniel Lellouch (Cern/Weizmann Institute)
TGC’s in a few words (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 Daniel Lellouch (Cern/Weizmann Institute)
Master 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) Daniel Lellouch (Cern/Weizmann Institute)
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: storeclasses, 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 Daniel Lellouch (Cern/Weizmann Institute)
Distributed 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 Manager JDBC Operator Operator Operator Daniel Lellouch (Cern/Weizmann Institute)
Barcodes • 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 Daniel Lellouch (Cern/Weizmann Institute)
