The construction of the ATLAS Semiconductor Central Tracker creates a greater level of complexity than we are used to even in Particle Physics. This arises from the number of components in the device itself, the size of the international collaboration involved, and the stringent quality control imposed by the hostile and inaccessible operating environment.

One of the stipulations of ATLAS quality control is the complete traceability of all components. In the SCT case this includes the 16000 silicon detector wafers which will be individually identified and tested. These must be tracked from receipt at any of the institutes involved, through testing and integration into larger assemblies and finally into the SCT itself.

We are creating a database to hold information about the construction and testing of the ATLAS SCT, which will be accessible from any of the participating institutes.

Objects in the database are tracked in four ways:

1. Each object is recorded in the database as an Item. An Item record contains the item’s identifying serial number as well as item type, manufacturer, manufacturer’s serial number, current location (institute) and time of entry into the database. It also flags whether the item has been incorporated into an assembly and whether it has passed all its required tests. Optional comments can be associated with an Item record.

2. Each time an item is tested a Test record is created. This records which item was tested, which type of test was performed, when, where and by whom the test was done, and whether the item passed or failed the test. Where appropriate, the actual test measurements will be recorded in a special test table. Optional comments and web links can also be associated with Test records. Certain test parameters will automatically be checked against predefined tolerances as they are entered in the database. The complete sequence of test results is kept.

3. When an item is mounted on an assembly, an Assembly record is created which associates the component item to its parent assembly item. One can easily find the position of any component item in its assembly, and given an assembly item one can easily list its components. There are automatic bookkeeping procedures, which keep the item’s location and status up to date when it is ‘assembled’ or ‘disassembled’ in the database.

4. When items are moved from one institute to another, a Shipment record is created, recording details such as origin, destination, carrier, etc. The shipped items are associated with the Shipment by Shipment Item records. The Shipment records allow an item’s location to be tracked in time. The database automatically updates an item’s location and ownership when the sender confirms a Shipment.

For details of Item, Test, Assembly and Shipment records see Appendix A.

The database follows a client-server model. The master copy of all of the data is held on an Oracle server at the University of Geneva. Client applications running on machines at participating institutes access the master server over the Internet.

The Geneva Oracle-8 database server provides the ability to store large amounts of structured data, with concurrent access by many clients. Data is retrieved and updated flexibly by means of the SQL language. Data security and integrity is ensured by means of data integrity rules, triggers, an access control scheme, and regular backups. All SCT database objects were generated by means of the Oracle Designer 2000 Rapid Application Development tool.

Three types of client are available: a PC/Macintosh application written with the Omnis 4th Generation Language, a web based client, and Java applications.

The Omnis client aims to provide a very easy and efficient environment for repetitive data entry tasks along with a flexible tool for querying the database contents and compiling reports and summaries for output to a printer or formatted data file. Wherever possible users are allowed to make selections from drop-down lists, in order to avoid typing errors. There is extensive validation of data as it is entered. In order to avoid network delays, data is first entered into a local copy or subset of the database, and this is used for most queries. This ‘local cache’ is then merged with the master copy at a convenient time. (1)

The web-based client avoids the necessity of installing special software on client machines. Any computer, including Unix workstations, with a web browser can access the master database via web pages held on an Oracle Web Server at the University of Geneva. The Oracle Designer 2000 tool was also used to generate most of the web based client application. (2)

Certain data, like manufacturers’ test data and LabView program output will be entered directly into the master server from ASCII text files by specially written Java applications, which are virtually platform independent. This is done at present for detector prototype tests using a client interface tool developed at Geneva University. Further applications can be developed quickly, taking advantage of Java’s object-oriented structure and useful third-party objects. The data transferred could represent several days’ test results written to a single text file. (3)

Secure access to the master server from all clients is ensured by password and special authentication procedures. In the case of the Java and web based client sensitive data like passwords can be encrypted.

All items in the database have a nine-digit decimal serial number, which identifies them uniquely. Generic, non-silicon detector, items have serial numbers assigned by the database in such a way that there is no conflict between items entered at different sites. Detector items have serial numbers compounded from a two-digit number assigned to each manufacturer followed by a ‘0’, and then the six binary coded decimal numbers marked on the scratch pads by the manufacturer. In addition to the scratch pads, each detector will have a block of text marked on it, like ‘ATLAS98HAM’, where the last three letters identify the manufacturer, ‘Hamamatsu’ in this case.

The number of serial number digits has been increased from eight to nine to be compatible with the proposed ATLAS wide Product Identification and Naming scheme (6).

The manufacturer’s internal serial number, for example ‘SDX35233-1’ is recorded optionally in the separate Manufacturer’s Serial Number field.

Since specifications for tests on SCT items are bound to evolve over time we have tried to design the database to grow to accommodate them in an orderly fashion.

The part of the design that is least likely to change much is the generic test information, which applies to any type of test.

• Each type of test has a short Test Description with a web pointer to a full specification. There is also a list that relates which tests are appropriate to particular types of item.

• Every test has a Test record with general details and a pass/fail result. A detector Visual Inspection would be recorded just in a normal Test record.

• Data like CV scans can be recorded in spreadsheet format in a Raw Data record. The entire raw data record is easily retrieved for display and analysis, but the database ignores its contents.

• Lists of strip defects can be recorded as Defects records associated with a test.

• Comments and Web Links can be attached to any of the tests.

• Tolerance limits can be associated with any test parameter.

The structures needed to hold parameters specific to particular tests are separated into special tables, which can be added as new tests are defined. Each special test record is associated with a generic Test record, and thus with comments, web links or a list of defects.

At present, only one special test record has been defined for detectors. The Detector Behaviour test records electrical measurements on prototype detectors, which may have been irradiated. New database tables will be created for the tests agreed for the Detector Quality Assurance Plans (4). These include mandatory Detector Manufacturer’s test and institute’s Visual Inspection and IV tests. There are also a number of separate tests to be performed on a subset of detectors, which will be recorded in a third table.

Details of test records so far defined are in Appendix A. Proposals for the new records are in Appendix B.

The database will be fully integrated with the EDMS, which is the official repository for all ATLAS documents (5). From database clients, users will have access to documents in the EDMS such as design data through hypertext links. From the EDMS, there will be read-only access to some of the database contents as well as a direct link to the database web interface. Two special tasks running in the background at the database and EDMS servers will keep the two systems in step as new data is added.

A production database for user validation has been available via the web interface since February 1999. (6)

The Omnis client is installed at several sites already, running in standalone mode, without access to the master server in Geneva.

By May 1999 there will be a version of the master database with a structure revised to accommodate detector identification by the manufacturers and the new detector quality assurance tests. A release of the Omnis client application will also allow merging of local caches with the master database.

(1) http://hepwww.ph.man.ac.uk/groups/atlas/SCTdatabase/Database.html

(2) http://polux0.unige.ch/sctprd/welcome.html

(3) http://polux0.unige.ch/sctprd/doc/otherlinks/java_app/index.html

(4) ATLAS SCT/Detector FDR/99/7 ‘Detector Quality Assurance Plans’

(5) http://edms.cern.ch/atlas/

(6) http://polux0.unige.ch/sctprd/welcome.html

The definitive description of the database structure is maintained at

http://schp5.unige.ch/atlas/atlaspage/db/doc/DataStructure.html

What follows is a summary of some of the relevant tables. The ‘description’ tables (Item Description, Test Description, Test List, Test Limits) are updated only by experts, and are normally accessed in read-only mode.

ITEM_DESCR: Item Description

CATEGORY Char (20) ‘Generic’ or ‘SiDetector’

IS_UNIQUE Boolean Used once only?

NO_COMPS Short int Number of components

DESCRIPTION Char (80) Description

URL Char (200) WWW link for more info

LAST_MOD Date Date record last updated

Primary Key: CTYPE

ITEMS: Details of an Item

SER_NO Long int Atlas Serial no.

MFR_SER_NO Char (35) manufacturer’s serial no.

MFR Char (20) manufacturer’s name

ENTRY_DATE Date Date entered into database

RECEIPT_DATE Date Date received at institute

LOCN_NAME Char(50) Current institute location

INITLS Char (4) Initials of user making entry

ASSEMBLED Boolean Mounted on an assembly?

PASSED Boolean Passed all necessary tests?

LAST_MOD Date Date record last updated

OWNER Char (30) Owner institute of the record

Primary Key: SER_NO

ITEM_CMNTS: Optional Comment about an Item

CMNT_NO Long int Comment number for this item

CMNT_DATE Date Date comment entered

INITLS Char (4) Initials of user making entry

CMNT_TEXT Char (400) Text of comment

LAST_MOD Date Date record last updated

OWNER Char (30) Owner institute of the record

Primary Key: CMNT_NO

ASSM_DESCR: Assembly Description

CTYPE Char (20) Item type of component

POSN Short int Position of component on assembly

POSN_DESCR Char (80) Description of position on assembly

LAST_MOD Date Date record last updated

Primary Key: ASSM_CTYPE, CTYPE, POSN

ASSM_ITEMS: Map Component Items onto Assembly

ASSM_SER_NO Long int Serial number of assembly

CTYPE Char (20) Item type of component

SER_NO Long int Serial number of component

POSN Short int Position of component on assembly

LAST_MOD Date Date record last updated

OWNER Char (30) Owner institute of the record

Primary Key: ASSM_CTYPE, ASSM_SER_NO, CTYPE, POSN

SHIP: Details of Shipment

LOCN_NAME Char (50) Name of shipping institute

SHIP_DATE Date Date of dispatch

INITLS Char (4) Initials of person sending shipment

SHIP_REF Char (35) Ref. number assigned by shipping institute

DEST_LOCN_NAME Char (50) Name of destination institute

DEST_INITLS Char (4) Initials of addressee

CARRIER Char (20) Name of carrier

CARRIER_REF Char (35) Ref. number assigned by carrier

NO_PACKS Short int Number of packages handled by carrier

GROSS_WT Float Gross weight of final package (Kg)

CONFIRM_DATE Date Date shipment confirmed by sender

LAST_MOD Date Date record last updated

OWNER Char (30) Owner institute of the record

Primary Key: SHIP_NO

SHIP_ITEMS: List of Items in a Shipment

SER_NO Long int Atlas Serial number of item

RECVD Boolean Item received at destination?

LAST_MOD Date Date record last updated

OWNER Char (30) Owner institute of the record

Primary Key: SHIP_NO, SER_NO

TEST_DESCR: Test Description

TEST_DESCR Char (80) Description of the test

NO_CHANS Long int Max number of channels to test

URL Char (200) WWW link for more info

TABLE_NAME Char (20) Name of database table for results

LAST_MOD Date Date record last updated

Primary Key: TEST_NAME

TEST_LIST: Links Tests to Item Types

CTYPE Char (20) Tested Item type

REQUIRED Boolean Test mandatory for these items?

LAST_MOD Date Date record last updated

Primary Key: CTYPE, TEST_NAME

TESTS: General Details of Tests

TEST_NO Long int ID number of test

RUN_NO Char (80) Data taking run no.

TEST_NAME Char (20) Name of test

TEST_DATE Date Date of test

LOCN_NAME Char (50) Location of test

INITLS Char (4) Initials of user

PASS Boolean Passed unconditionally?

PROBLEM Boolean Problems encountered?

LAST_MOD Date Date record last updated

OWNER Char (30) Owner institute of the record

Primary Key: TEST_NO

TEST_CMNTS: Optional Comments on Tests

CMNT_NO Long int Comment number for this test

CMNT_TEXT Char (400) Text of comment

LAST_MOD Date Date record last updated

OWNER Char (30) Owner institute of the record

Primary Key: CMNT_NO

DEFECT_DESCR: Descriptions of Named Defects

DEFECT_DESCR Char (100) Description of the defect

LAST_MOD Date Date record last updated

Primary Key: DEFECT_NAME

DEFECTS: Channels Tested with Defects

DEFECT_NAME Char (20) Name for the defect

CHAN_1ST Long int First channel with the defect

CHAN_LAST Long int Last channel with the defect

URL Char (200) WWW link for more info

LAST_MOD Date Date record last updated

OWNER Char (30) Owner institute of the record

Primary Key: TEST_NO, DEFECT_NAME, CHAN_1ST

TEST_LIMITS: Warning and Reject Limits for Test Parameters

TEST_NAME Char (20) Name of test

PARM_NAME Char (80) Name of test parameter

MFR Char (20) Manufacturer’s name (can be ‘any’.)

UPPER_WARN Float Upper warning limit

LOWER_WARN Float Lower warning limit

UPPER_REJECT Float Upper reject limit

LOWER_REJECT Float Lower reject limit

PARM_DESCR Char (40) Description of parameter with units

LAST_MOD Date Date record last updated

Primary Key: CTYPE, TEST_NAME, PARM_NAME, MFR

TEST_RAWDATA: Raw Data Test

FILENAME Char (100) Name of original data file

RAW_DATA Binary Block of tab delimited text data

LAST_MOD Date Date record last updated

OWNER Char (30) Owner institute of the record

Primary Key: TEST_NO

We include here descriptions of proposed new test tables based on the Detector Quality Assurance Plans (4).

TEST_DET_MFR: Manufacturer’s Detector Test

BATCH_NO Char (40) Manufacturer’s batch number

SUBSTR_ORIGIN Char (40) Substrate origin

SUBSTR_ORIENT Char (40) Substrate orientation

THICKNESS Long Int Thickness (microns)

V_DEP Float Depletion volts

TEMPERATURE Float Temperature during IV (Celsius)

IV_RAWDATA Binary Block of tab delimited IV data

Primary Key: TEST_NO

Additional manufacturer’s information would be stored in other tables, e.g.:

ITEMS table:

SER_NO Atlas serial number = (Mfr_No * 10⁷) + Scratch_Pad_No

CTYPE Detector type, e.g., ‘bmSiDetectorOut’ for barrel outer Si detector.

MFR Manufacturer’s name

MFR_SER_NO Manufacturer’s serial number, e.g., ‘SDX35233-1’

RECEIPT_DATE Date of receipt by institute of batch of detectors

TESTS table:

TEST_NO Test ID number, assigned by database

SER_NO Atlas serial number

TEST_CMNTS table:

Any comments by manufacturer.

DEFECTS table:

Lists of pinholes, neighbour shorts, discontinuities. The percentage of good strips per batch can be derived by the database from the DEFECTS table.

TEST_DET_IV: Institute’s Detector IV Test, mandatory.

TEMPERATURE Float Temperature during IV (Celsius)

RAD_DOSE Float Radiation dose (10¹⁴ protons/cm²)

IV_RAWDATA Binary Block of tab delimited IV data

Primary Key: TEST_NO

TEST_DET_OPT: Optional Detector Test Results.

TEMPERATURE Float Temperature during test (Celsius)

RAD_DOSE Float Radiation dose (10¹⁴ protons/cm²)

V_DEP Float Depletion voltage (volts)

C_INTERSTRIP Float Inter strip capacitance (pF/cm)

C_INTERSTRIP_SD Float Inter strip capacitance std. deviation (pF/cm)

C_COUPLING Float Coupling capacitance (pF/cm)

C_COUPLING_SD Float Coupling capacitance std. deviation (pF/cm)

V_FLAT Float Flatband voltage (volts)

Primary Key: TEST_NO

The strip integrity test uses existing TESTS and DEFECTS tables.

There will be an automatic procedure for comparing leakage currents, strip defects, bias resistance, and depletion voltages with manufacturer’s measurements.

Radiation dose will normally be zero for all but a sample of production detectors.