ILC Cavity Data Management

Final ReportJune 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 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.

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

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!

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– 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

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