Transcript Document 7735650

ILC Cavity Data Management
Final Report
June 11, 2007
Peter Kasper
Team Members









Jamie Blowers
Denise Finstrom
Peter Kasper (leader)
Michele McCusker-Whiting
Janice Nelson
Jerzy Nogiec
Joe Ozelis
Marc Paterno
Claude Saunders
Charter: The Problem

The US effort on fabricating and testing SCRF cavities and
cryo-modules is occurring at numerous sites across the
country, and each is handling the management of cavity-related
process data in their own way. In addition, some sites (e.g.
Fermilab) have numerous different sub-organizations working
on cavity processing, and each of these is also handling data
management in their own way. The result is that much data is
being generated, but it is spread throughout numerous
systems. This lack of data organization results in the inability to
easily locate all data related to a specific cavity and cryomodule. This can then lead to numerous problems, one of
which is the inefficiency at best, and inability at worst, to be
able to appropriately use the data for understanding the
technology and for making improvements.
What We Did

Examined existing cavity database systems
–
–

Looked at a commercial option
–


Pansophy (JLab)
DESY
Tecnomatix (UGS)
Produced a “Requirements Document”
Evaluated options against requirements
–
Functional and technical assessments
Tecnomatix – Not recomended


Looked promising when demoed
Licensing costs looked prohibitive (but
negotiable?)
–

Tried to set up an evaluation
–
–

$2K for each report client user
Cost ~30K in consulting fees
Took too long to negotiate
UGS bought up by Siemens!
Functional Assessments


Supported input methods
Representative reports
–
–
–
–
–
–
–
–
Ad hoc (user defined) reports
Cavity process history
Process details
Cavity performance history & snapshot
Cavity discrepancy report
Component genealogy
Correlate performance with 24/7 monitoring
Production tracking
Technical Assessments








Schema style
Software technology components
Security features
Integration API
Learning curve/training
Database independence
System support
Licensing
Pansophy

Stongly process oriented
–

Schema design creates severe problems that
get worse with time
–
–

JLab chose to create Pansophy rather than adopt
the DESY system partly for this reason
Difficult to provide automatic data entry
Difficult to maintain, modify, and create reports
Some (unnecessary) licensing costs
DESY

Weak process integration
–
Unable to produce process related reports



No access to process details or discrepancy reports
Unable to produce a production activity report
Complete dependence on Oracle is a major
weakness
–
–
Lack of database independence
High licensing costs
Conclusions

Both options require significant work to make
them comply with the requirements
–


Comparable effort to starting afresh
Pansophy is the solution that is closest to
meeting our needs
The current form has design flaws that …
–
–
Make it difficult to maintain over the long term
Make it difficult to share data with other systems
Extra information

DESY system is being reworked to
–
–

Replace a graphics package that is no longer
supported by Oracle
Improve the schema performance
JLab wants to produce a new version of
Pansophy that fixes its design flaws
–
–
They are keen to collaborate with Fermilab in this
It is not clear how extensive are the changes that
they are planning
Recommendation


If possible, negotiate a collaboration with
JLab to rework Pansophy into something that
meets our needs
Otherwise produce a merger of the DESY
and Pansophy concepts
–
–
Use open source technologies
Estimate 6-9 months for working system