Production Database Objects¶

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.

Posting Information to PDB¶

Code is King¶

To input and access information from a predefined set of options (e.g. componentType, institution, stage) in the PDB the relevant parameter code must be used.

Codes can be found using the Unicorn webApp or using listing API commands like listComponentTypes, listTestTypes, listInstitutions. See PDB API documentaion details and more examples.

Querying Example

To a list of components currently at an institution (using the API listComponents command) the uploaded json must include the:

'currentLocation': "GL"

here "GL" is the instiution code for Glasgow.

Registration examples

To register a module component for the pixels project (using the API registerComponent command) the uploaded json must include:

'project': "P",
'componentType': "MODULE"

here "P" is the project code for pixels and "MODULE" is the componentType code.

To get an upload a testRun for bow measurements for strips modules (using the API uploadTestRunResults command) the json must include:

'project': "S",
'componentType': "MODULE"
'testType': "MODULE_BOW"

here "S" is the project code for strips, "MODULE" is the componentType code and "BOW" is the testType code.

All parameter information sent to the PDB must also be specified using codes, e.g. "BOW", "TEMPERATURE", "I_500".

NB codes are usually uppercase, though there are exceptions. Please check the specific data-strucuture.

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