1 / 18

TGC Stock and Production Data Base

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

jackie
Download Presentation

TGC Stock and Production Data Base

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

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

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

  4. Daniel Lellouch (Cern/Weizmann Institute)

  5. Daniel Lellouch (Cern/Weizmann Institute)

  6. Daniel Lellouch (Cern/Weizmann Institute)

  7. Daniel Lellouch (Cern/Weizmann Institute)

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

  9. Daniel Lellouch (Cern/Weizmann Institute)

  10. Daniel Lellouch (Cern/Weizmann Institute)

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

  12. Daniel Lellouch (Cern/Weizmann Institute)

  13. Daniel Lellouch (Cern/Weizmann Institute)

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

  15. Daniel Lellouch (Cern/Weizmann Institute)

  16. Daniel Lellouch (Cern/Weizmann Institute)

  17. Daniel Lellouch (Cern/Weizmann Institute)

  18. Daniel Lellouch (Cern/Weizmann Institute)

More Related