LSST AHM 2015 • Bremerton, WA • 2015 1
eManufacturing, Sensor Analysis and Test Data Cura8on Overview
Richard Dubois
LSST Community 2015 Aug 19, 2015
LSST AHM 2015 • Bremerton, WA • 2015 2
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
LSST AHM 2015 • Bremerton, WA • 2015 3
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
LSST AHM 2015 • Bremerton, WA • 2015 4
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
LSST AHM 2015 • Bremerton, WA • 2015 5
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
LSST AHM 2015 • Bremerton, WA • 2015 6
Gecng to Test Stand 3: Receive, then Metrology
prereqs
choices
Req’d info
LSST AHM 2015 • Bremerton, WA • 2015 7
Test Stand 3
LSST AHM 2015 • Bremerton, WA • 2015 8
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
LSST AHM 2015 • Bremerton, WA • 2015 9
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
LSST AHM 2015 • Bremerton, WA • 2015 10
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
LSST AHM 2015 • Bremerton, WA • 2015 11
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
LSST AHM 2015 • Bremerton, WA • 2015 12
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
LSST AHM 2015 • Bremerton, WA • 2015 13
eTraveler Web App
LSST AHM 2015 • Bremerton, WA • 2015 14
DB tables, par88oned
LSST AHM 2015 • Bremerton, WA • 2015 15
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
LSST AHM 2015 • Bremerton, WA • 2015 16
AVer Ingest (I&T example)
LSST AHM 2015 • Bremerton, WA • 2015 17
Sample of Sensor Receiving process step
LSST AHM 2015 • Bremerton, WA • 2015 18
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
LSST AHM 2015 • Bremerton, WA • 2015 19
Basic file information
Directory view
Click to download & view
http://srs.slac.stanford.edu/DataCatalog/?experiment=LSST
LSST AHM 2015 • Bremerton, WA • 2015 20
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
LSST AHM 2015 • Bremerton, WA • 2015 21
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.
LSST AHM 2015 • Bremerton, WA • 2015 22
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
LSST AHM 2015 • Bremerton, WA • 2015 23
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