PDB Object Attributes and Features¶

This section details the generic structure of objects required for registry in the Production Database (PDB): components, testRuns, batches, etc.

More details can be found in the PDB API documentaion.

Object Attributes¶

Component Types¶

Basic Information¶

Name: Human readable name of a component Type
Code: This is the code you have to set-up by which the component type is known in the database. It's best to use upper case and underscored for the code
Description: Describe your component type
Id: this is set-up automatically by the database when you create a new component type. This is the identifier internally used by the database, when querying the component type
Category: It is one of the following

Category	Description
Item	An individual item with no components assembled into it
Assembly	Something that consists of several children components being combined together (e.g. a module)
Bulk	A pile of countable items with no distinguishing features, e.g. a pack of screws, a box of bi-packs etc
Wafer	Object split into a defined number of children of a certain type, e.g. an ABC130 ASIC wafer
Panel	Similar to wafer: created as one object that contains several children, e.g. a hybrid array (with hybrids + coupons)
Material	A pile of material from which a number of objects can be made without knowing precisely how many (e.g. a roll of carbon fibre which is cut up for face sheets)
Reusable	Objects which need to be traced during production, but do not actually go into the detector (e.g. tools, test frames, test panels, etc.)

Project: This is either 'P' for Pixels, 'S' for Strips, 'CE' for common Electronics or 'CM' for Common Mechanics
Subproject: In case of Pixels the subprojects are 'PG' for pixel general, 'PI' for pixel inner system, 'PB' for pixel barrel or 'PE' for pixel endcap. In case of strips it is 'SG' for pixel general, 'SB' for strip barrel, 'SE' for strip endcap. Common Electronics and Common Mechanics do not have subproject codes.
State: This indicates if if component type can be used by community. The states are 'created' when they are being set-up, 'active' when they can be used by the community, 'suspended' when they are not supposed to be used temporarily and 'closed' if they they are obsolete and should no longer being used. The latter can happen if testing components.
ATLAS Serial Number: The serial number convention is documented in edms. Serial numbers can be attributed automatically or manually. Automatically implies that when a new component is registered, the database will find the previous object with the same YY identifier and register the new object with that serial number +1. Every other type of serial numbering (e.g. with encoding done according to vendor serial number) needs this function de-activated, so that serial numbers can be entered manually/through a script. This functionality is also available in case of properties (see below) are defined to match some of the first dibits of the last 7 digits of the SN. If the serial number is not know when registering the part in the database it can be assigned later.
SN Component Identifier: This is the YY code of the serial number which is set for all component subtypes.
Child registration: This is only relevant if the category is an assembly, a wafer of panel. For any other category 'not available' is diplayed.

Flags¶

Flags are attached to a component and can be added in any stage to add extra information to a component. Examples are 'part took part in QA test, that it has 'small issue observed' or similar. Flags are pre-defined and have a name and a code similar to the component type name and code.

(Sub-)Types¶

Types from the same component type share the same parameters, stages and associated tests. For example, tests are the same for all sensors, independent of geometry In this case it makes sense to define one sensor component (with tests and stages) and then have several sub-types (SS, LS, R0, R1 etc) which inherit this information from all sensors. This reduces complexity, number of tests to be updated if updates are needed etc. In case these sub-types are too different (e.g. cooling loops stave/endcap), it is better to define them as different component types If no Types are needed, the list of Types will be empty.

Every sub-type has

Checking Object Data Structures¶

Unicorn¶

Object data-structures can be viewed (and copied) via the Unicorn GUI by navigating to the the relevant object type (e.g. pixels modules componentType, strips module bow tesType) and clicking the Show Dto Sample button.

API¶

The Unicorn API allows scripts query generic object structures using generateComponentTypeDtoSample and generateTestTypeDtoSample commands for components and tests, respectively. This returns a json object with the relevant parameter keys for the object.

by default this query returns only the required keys. The full structure can be return setting the required flag to False (default True).

NB The returned object with have pre-filled values which must be replaced. Sometimes the the pre-filled values can look like meaningful data (e.g. breakdown voltage is 0V, humidity is ~5%) so be sure to set missing values in such a way that it no-one will later mistake it for genuine data.

Registering Objects¶

Enough relevant information must be supplied to identify object.

Components¶

Component objects include header information along with properties.

Components are registed using createComponent API command.

Header information¶

project: ITk project - Strips (S), Pixels (P), Common Electronics (CE), Common Mechanics (CM)
subproject: sub-project of ITk Project, e.g. PG for pixels general, SB for strips barrel
componentType: type of component, e.g. MODULE, PCB, PWB
type: sub-type of component
institution: institute where component registered
serialNumber (optional): if componentType allows manual specification
alternativeIdentifier (optional): if user wishes to supply it

Properties¶

Information relevant to performance of components, e.g. manufacturer, batch number, assembly date.

Component property information is supplied as a dictionary to the properties key. The structure is defined for the specific componentType. This can be checked via Unicorn GUI or getComponentTypeByCode for components.

Additional Information (not set by user)¶

id: unique mongoDB id (can be used by getComponent)
code: unique code (can be used by getComponent)
cts: creation timestamp

Test Runs¶

TestRun objects include header information along with properties and results.

TestRuns are registed using uploadTestRunResults API command.

Header information¶

component: identifier (id, code, serialNumber) of component to associate test
testType: type of test to upload to
institution: institute where test took place
stage: stage of component to upload test at (the same testType can appear at multiple component stages)
date: date on which test was performed
runNumber: additional identifier for specific test run
passed: binary to flag success of test
problems: binary to flag issues with test

Properties¶

Information relevant to performance of test, e.g. environmental conditions, analysis version.

Test property information is supplied as a dictionary to the properties key. The structure is defined for the specific componentType. This can be checked via Unicorn GUI or getTestTypeByCode for tests.

Results¶

Data from the test, e.g. bow (float), voltage (array), metrology results (dictionary).

Test results information is supplied as a dictionary to the properties key. The structure is defined for the specific componentType. This can be checked via Unicorn GUI or getTestTypeByCode for tests.

Additional Information (not set by user)¶

id: unique mongoDB id (can be used by getTestRun)
cts: creation timestamp

Retroactive Uploads¶

Additional information maybe supplied for the purposes of retroactive uploads, i.e. test data uploads where the component does not currently have to be at the test institution or stage, provide it previously has been.

To upload test data retroactively the isRetroactive flage must be set to True (default False).

Batches (TBC)¶

Batch objects include header information along with properties.

Header information¶

batchType: type of batch to register
number: name of batch (identifier for later searches)
institution: institute where component registered

Properties¶

Information relevant to group of objects in batch, e.g. manufacture information.

Batch property information is supplied as a dictionary to the properties key. The structure is defined for the specific componentType. This can be checked via Unicorn GUI.

Additional Information (not set by user)¶

id: unique mongoDB id (can be used by getComponent)
cts: creation timestamp