ILC Cavity Data Management

1
ILC Cavity Data Management

• Final Report
• June 11, 2007
• Peter Kasper

2
Team Members

• Jamie Blowers
• Denise Finstrom
• Peter Kasper (leader)
• Michele McCusker-Whiting
• Janice Nelson
• Jerzy Nogiec
• Joe Ozelis
• Marc Paterno
• Claude Saunders

3
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
  cryo-module. 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.

4
What We Did

• Examined existing cavity database systems
• Pansophy (JLab)
• DESY
• Looked at a commercial option
• Tecnomatix (UGS)
• Produced a Requirements Document
• Evaluated options against requirements
• Functional and technical assessments

5
Tecnomatix Not recomended

• Looked promising when demoed
• Licensing costs looked prohibitive (but
  negotiable?)
• 2K for each report client user
• Tried to set up an evaluation
• Cost 30K in consulting fees
• Took too long to negotiate
• UGS bought up by Siemens!

6
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

7
Technical Assessments

• Schema style
• Software technology components
• Security features
• Integration API
• Learning curve/training
• Database independence
• System support
• Licensing

8
Pansophy

• Stongly process oriented
• JLab chose to create Pansophy rather than adopt
  the DESY system partly for this reason
• Schema design creates severe problems that get
  worse with time
• Difficult to provide automatic data entry
• Difficult to maintain, modify, and create reports
• Some (unnecessary) licensing costs

9
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

10
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

11
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

12
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