eManufacturing,-Sensor-Analysis-and- TestData Curaon Overview · TestData Curaon Overview-Richard-Dubois-richard@slac.stanford.edu--LSSTCommunity2015 Aug-19,-2015-!LSST AHM 2015 •

LSST AHM 2015 • Bremerton, WA • 2015 1

eManufacturing, Sensor Analysis and Test Data Cura8on Overview

Richard Dubois

[email protected]

LSST Community 2015 Aug 19, 2015


Context from the Telescope Team

I believe there are two major characteris8cs we should consider: how comprehensive and how user friendly eTraveler is. The laMer one is obviously related to the cost of adop8ng it as general project tool, while the former indicates the poten8al gain. I consider it comprehensive if it is capable of providing -‐ at least as pointers to archived, controlled documents -‐ the en8re Acceptance Data Package for a subsystem or major component:

•  Cer8ficates of Compliance for all relevant requirements, specifica8ons and interfaces •  Any change requests, non-‐conformance and devia8on reports and/or requests for

waiver •  Approved acceptance test procedure •  Qualifica8on and/or acceptance test results •  Calibra8on and cer8fica8on requirements records •  Material and/or process cer8fica8ons •  Traceability data •  Safety documenta8on and constraints •  Shipping, handling and storage plans •  Opera8on, maintenance and repair manuals, •  Deliverable as-‐built technical documenta8on


Introduc8on

•  eManufacturing

–  Traveler –  Procedures –  Logbook

•  Camera Data Management –  Data products –  Data archive & access tools –  WorkFlow engine for bulk analysis

Integrated system for all camera: •  Hardware types •  Locations •  Phases – test, production, operations


Key Documents

•  SoVware Standards – LCA 10099 •  Electro-‐Op8cal Test Algorithms – LCA 10103 •  Data Cura8on Specifica8on – LCA 10127 •  eTraveler Specifica8on – LCA 10138-‐A •  Cura8on and eManufacturing requirements – LCA 10139 •  Job Harness Specifica8on – hMp://www.slac.stanford.edu/~jrb/

lsst/jh/developer.html •  FITS Standards – LCA 10140


Understanding the Context of the Data: eManufacturing •  Track acceptance tes8ng and assembly

–  Not just sensors –  Applicable to any type of component; sensors are the first example of serious use –  Does not have to be hardware –  “traveler” that describes the movements and workflow –  Record the parameters important to the data taking: data provenance –  Link the test data and parameters to the movements and workflow –  Keep the 200+ sensors organized as they become parts of raUs

•  Rigour –  Provide the operator interface to walk through the recipes associated with the workflow –  Every step is defined and linked, with outcomes recorded

•  Distributed Ac8vi8es and Transparency –  AcXviXes span 9 Xme zones! –  Replace paper with the web: any authorized person can track the progress from overall status to

drilling down to individual steps in the workflow

•  Longevity and Access –  Collect all the data and provide easy access to them into the OperaXons phase –  We expect this data to be important for input to simulaXons and for performing systemaXcs studies


Gecng to Test Stand 3: Receive, then Metrology

prereqs

choices

Req’d info


Test Stand 3


What Will Be Curated?

•  Data from various venues –  BNL, Marseille, Paris, Penn, SLAC, vendors

•  Types of tests –  Pixel-‐based: dark current, QE, Fe55, linearity, gain, etc –  Metrology: sensor, raU, focal plane –  Tests of electronics boards (ASPIC, CABAC), filters, lenses, etc

•  Data Products –  Pixel data (images) –  Metrology data –  Trending, configuraXon, etc –  Derived data products: gain maps, bad pixels maps, metrology maps, etc


Opera8ons Overview: Database, Web Interface, Job Harness, eLog

Job Harness

eLog

Database

Test Stand/ Local Archive

or

Perform manual task

Set up and run scripted task

entries as needed

Copy data products to central archive

Register results of task in db


Process Control Requirements

•  Detailed needs: hMps://confluence.slac.stanford.edu/display/LSSTCAM/Procedures+Defini8on+Working+Group

•  Extracted key elements –  Ability to specify hyperlinks to documents within a step –  Possibility of special warnings or cauXons associated with steps –  Branch points or condiXonal steps

°  VariaXons in hardware °  Test plans that call for only a fracXon of components to be tested

–  Login or authenXcaXon of the user, who then becomes responsible for compleXng the steps during that session

–  Ability to stop work at any Xme –  Manual data entry –  Script execuXon –  Free-‐form informaXon input –  CompleXon approval for secXons, with further work condiXonal upon these approvals –  NCR handling –  Report generaXon –  Revision control and versioning for process traveler descripXons

•  Extensive interviews with Mar8n Nordby for func8onality and look and feel


eTraveler Func8onality

•  Capture hardware element proper8es –  Hardware IDs –  All acXviXes related to hardware items –  Parent/child relaXonships (eg sensor is in a raU)

•  Define and drive processes –  Use YAML to specify the processes –  Versioning –  Allow for condiXonal steps and NCRs – modificaXons to standard processes –  Different levels of user roles –  Processes include manual operaXons as well as tests and analyses

•  Examina8on of state –  Web interface to inspect

°  Each piece of hardware °  Completed steps °  Work to be performed

–  Report generaXon


eTraveler Defined

λ Constituents:

•  MySQL db hosted at SLAC. eTraveler only. Modest size •  Handfuls of concurrent users; < 10 million rows (est.)

•  Web server hosted at SLAC, accessible everywhere. Not dedicated to eTraveler.

•  Applications for •  creating procedure descriptions •  registering hardware components •  executing a procedure •  report generation, data portal


eTraveler Web App


DB tables, par88oned


YAML input of Process Defini8ons

•  +Name: Sensor_T01 •  +HardwareType: ASPIC chip •  +Descrip8on: Sensor delivery and inspec8on •  +Sequence •  + Name: Sensor at TS1 •  + Descrip8on: Opera8ons done at test stand 1 •  + Prerequisites: -‐ •  + Name: TS1 ready •  + Descrip8on: TS1 has been commissioned •  + PrerequisiteType: TEST_EQUIPMENT •  + Sequence: •  + Name: Sensor receive •  + Descrip8on: Unpack; discard loose packing •  + Name: Sensor move to anteroom •  + Name: Sensor file vendor data •  + Instruc8onsURL: hMp://.../sensor/vendorForm.html •  + Name: Sensor init dsta logging •  + Instruc8onsURL: hMp://www.stanford.edu/~jrb/eTraveler/instruc8ons/sesnor/initLogging.html •  + Name: Sensor coffin clean •  + Descrip8on: Full cleaning procedure •  + Sequence: •  + Name: Sensor coffin clean_1 •  + Prerequisites: •  + Name: gloves •  + PrerequisiteType: CONSUMABLE •  + Name: cleaning agent 1 •  + PrerequisiteType: CONSUMABLE •  + Instruc8onsURL: hMp://www.stanford.edu/~jrb/eTraveler/instruc8ons/sensor/clean_coffin_1.html •  + Name: Sensor coffin clean_move •  + Descrip8on: Move coffin into C10K •  + Name: Sensor coffin clean_2 •  + Prerequisites: •  + Name: gloves •  + PrerequisiteType: CONSUMABLE •  + Name: cleaning agent 2 •  + PrerequisiteType: CONSUMABLE •  + Instruc8onsURL: "hMp://www.stanford.edu/~jrb/eTraveler/instruc8ons/sensor/clean_coffin_2.html" •  + # If clean_coffin_2 is iden8cal to clean_coffin_1, clone •  + # clean_coffin_1 rather than defining new step here

etc


AVer Ingest (I&T example)


Sample of Sensor Receiving process step


Data Cura8on

•  Automa8cally mirror data from tes8ng sites –  Fetch and register files from contribuXng sites –  AutomaXcally extract metadata from the FITS headers –  MulXple copies can be registered – allows for mulXple sites of files

°  Mirror files to all sites that want them

–  Use GridFTP between SLAC and BNL; iRODS to Paris – demonstrated 40 MB/s to BNL

•  Registra8on –  Allows use of standard web browser for locaXng, previewing and downloading files. –  Allows use of command line interface for database queries.

•  Metadata Handling –  Data Catalogue automaXcally “crawls” all registered files extracXng basic

informaXon (size, type, date, etc.) as well as checking their health and existence –  Plug-‐in code recognizes and processes selected files in custom manner, in this case

dump FITS primary header -‐> data catalog metadata –  Database queries based on header metadata


Basic file information

Directory view

Click to download & view

http://srs.slac.stanford.edu/DataCatalog/?experiment=LSST


EO Test Stand Opera8on: CCS, eTraveler, eLog

eTraveler: what do I do next, via web

app

eLog: Clock in, record things, images etc of note

Linux prompt: Execute the test per eTraveler recipe – run in Job Harness

Analysis: Plots etc

from test via web app

Image Display: Quick look at image via CCS

Trending: Environmental info, via CCS

eLog: eTraveler, JH, CCS leave breadcrumb

trail in eLog

JH: Drive hardware via CCS console, run iniXal

analysis, record outcome in eTraveler, Results db’s


Sundry items

•  Demo of Data Portal and Test Stand 3 traveler

•  Using eTraveler for approvals –  Can use process traveler to define approval processes –  Tied to the enXty of interest, be it a hardware or traveler instance

•  Roles and Permissions –  Tied to the camera people database –  Allow different levels of permission for restarXng work, approvals etc

•  Job Harness –  Allows for running scripts, and linked scripts –  Can be used for moving files around

•  eLog –  Provided by FNAL. eTraveler interface allows for easy eLog entries, automaXcally tagged with

the hardware/test condiXons.


Context from the Telescope Team -‐ Discussion

I believe there are two major characteris8cs we should consider: how comprehensive and how user friendly eTraveler is. The laMer one is obviously related to the cost of adop8ng it as general project tool, while the former indicates the poten8al gain. I consider it comprehensive if it is capable of providing -‐ at least as pointers to archived, controlled documents -‐ the en8re Acceptance Data Package for a subsystem or major component:

•  Cer8ficates of Compliance for all relevant requirements, specifica8ons and interfaces •  Any change requests, non-‐conformance and devia8on reports and/or requests for

waiver •  Approved acceptance test procedure •  Qualifica8on and/or acceptance test results •  Calibra8on and cer8fica8on requirements records •  Material and/or process cer8fica8ons •  Traceability data •  Safety documenta8on and constraints •  Shipping, handling and storage plans •  Opera8on, maintenance and repair manuals, •  Deliverable as-‐built technical documenta8on


Glossary

•  CCS •  Camera control system: Java system to drive the Camera system hardware, communicating over software buses.

Provides a console interface via scripting or gui’s, and a trending system for time sequence of environmental data.

•  Analysis Database •  Output of results from sensor analysis scripts

•  eLog •  Electronic logbook: Java web application provided and hosted by FNAL. Can communicate via REST interfaces

with other applications, as well as usual human interaction to record comments, images etc. •  eTraveler

•  Web application on top of mySql database: control and tracking of all operations and data products in assembly process

•  Job Harness •  Python script: runs scripts that drive hardware and perform first analysis. Communicates ins and outs with

eTraveler database. •  Workflow engine

•  SLAC SCA tool for automated running of large numbers of batch jobs. Supports complex graphs of processing. Central submission; multiple remote execution locations. Web application for operation, in addition to command line interface for bulk operations.

•  Data Catalogue •  SLAC SCA virtual filesystem, supporting arbitrary associated metadata. Web and command line interfaces.

•  OGP •  Metrology measurement machine

•  SCA •  SLAC Scientific Computing Applications division of PPA. Supports a suite of data handling and collaboration tools

for several experiments

End of Presenta8on