Difference between revisions of "ESR"
| Line 1: | Line 1: | ||
| − | |||
| + | == Attendance == | ||
| − | + | Kimber, Bickley, Creel, Hiatt, Kowal, Michaud, Smith, Sperlazza | |
| − | |||
| − | == | + | == Agenda and Notes == |
| − | + | ||
| − | + | '''1. Logistics''' | |
| + | |||
| + | Engineering staff use ENGINF, others use a 'home' account | ||
| + | |||
| + | Weekly meeting (~1-1.5 hours), time TBD | ||
| + | |||
| + | Wiki, to be used for: | ||
| + | *meeting agenda/minutes | ||
| + | *personal note spaces | ||
| + | *uploading of files pending | ||
| + | |||
| + | '''2. Round table, initial impressions''' | ||
| + | |||
| + | Lively discussion of what we have been asked to do. | ||
| + | |||
| + | '''3. Start of brainstorming''' | ||
| + | |||
| + | How do we ''measure'' reliability? Metrics? | ||
| + | |||
| + | Standardize some of the definitions, terminology (reliability vs availability) | ||
| + | |||
| + | The goals of the team should be more tightly defined as we progress (staged goals?) | ||
| + | |||
| + | Do we care if something breaks when machine is not running? This needs better defining. Maybe individual groups care (for tracking) but it does not affect the machine. At present we do not track failures during the SAD periods. | ||
| + | |||
| + | Tools for data gathering. ''(Maybe Randy could demonstrate the Downtime Manager (DTM) next meeting for those that have not seen it?)'' | ||
| + | |||
| + | Many of the components that make up the machine are running to their limits. Operational regimes and their effect on reliability appear to have not been widely considered. | ||
| + | |||
| + | The group (or designees) may have to look at historical data. | ||
| + | |||
| + | Steve Suhring et. al. looked at reliability during the 6GeV era, other teams/individuals have looked as well. Why haven't any long term recommendations been adopted? (were there any?) | ||
| + | |||
| + | ''Return on investment'' of projects was discussed. Downtime costs $$. One should be able to justify the cost (money/time) of an upgrade by showing that it will save x dollars in the future. | ||
| + | |||
| + | == Action Items == | ||
| + | |||
| + | Setup weekly meeting '''(Kimber)''' <span style="color:#008000"> (done!) </span> | ||
Revision as of 09:12, 30 September 2016
Attendance
Kimber, Bickley, Creel, Hiatt, Kowal, Michaud, Smith, Sperlazza
Agenda and Notes
1. Logistics
Engineering staff use ENGINF, others use a 'home' account
Weekly meeting (~1-1.5 hours), time TBD
Wiki, to be used for:
- meeting agenda/minutes
- personal note spaces
- uploading of files pending
2. Round table, initial impressions
Lively discussion of what we have been asked to do.
3. Start of brainstorming
How do we measure reliability? Metrics?
Standardize some of the definitions, terminology (reliability vs availability)
The goals of the team should be more tightly defined as we progress (staged goals?)
Do we care if something breaks when machine is not running? This needs better defining. Maybe individual groups care (for tracking) but it does not affect the machine. At present we do not track failures during the SAD periods.
Tools for data gathering. (Maybe Randy could demonstrate the Downtime Manager (DTM) next meeting for those that have not seen it?)
Many of the components that make up the machine are running to their limits. Operational regimes and their effect on reliability appear to have not been widely considered.
The group (or designees) may have to look at historical data.
Steve Suhring et. al. looked at reliability during the 6GeV era, other teams/individuals have looked as well. Why haven't any long term recommendations been adopted? (were there any?)
Return on investment of projects was discussed. Downtime costs $$. One should be able to justify the cost (money/time) of an upgrade by showing that it will save x dollars in the future.
Action Items
Setup weekly meeting (Kimber) (done!)
