Equipment management and INB

1. Equipment management and INB CMS perspective INB traceability requirements Implications, need for DB Synergy with Equipment Management CMS path from Rack wizard towards a full Equipment Management DB Comments and conclusions on INB and Databases Reminder that this is not a new story……

2. INB traceability requirements Operation as INB requires that any material from within the INB perimeter (France) which could reach the public domain as waste or otherwise must be “traceable”. ie:- -must know the location vs time of all objects which are, or could turn out to be, radioactive. -must also be able to superimpose the positional history of an object onto a calculated activation map, so that, given the material composition of the object, the level of activation observed can be justified. -objects removed from certain defined zones must be RP screened and the result and date of screening linked to the object. -some objects are tagged as radioactive by definition (within “ZDN” zone). -this ZDN boundary may change (expand) with time. (eg as LHC lumi rises)

3. Implications, need for DB -All objects likely to move location must be labelled unambiguously -Labelled objects must be associated to physical locations as a function of time -The labelling scheme must allow for an object to spawn daughter objects with a shared common history, followed by individual different histories. -Retroactive definition of previously untraced objects and physical locations must be possible. (eg when dismantling). Self-evidently a case for a relational database: must be user friendly, correspond to reality be backed-up and active for life of expt and beyond

4. Synergy with Equipment Management Experiments need to manage their equipment hardware configuration -detailed inventory of installed and spare items -fault history used in diagnostic support -configuration specific calibrations or set-up information dependent on the exact hardware configuration and needed by the online system at run start. In the past, databases often custom-built by individual subdetectors Coherence patchy: long-term support and backup often absent CMS commissioning task force brainstorming on managing the attribution of equipment to racks led to the “Rack Wizard” database and user interface implementation by Frank Glege, incorporating the concepts needed for an overall equipment management database, satisfying INB automatically.

5. CMS EMD developed from “Rack Wizard” “Wizard” used by CMS and several other experiments (and briefly LHC) for planning and managing the physical configuration of equipment in Racks. No central support. CMS does not have the resources to provide this service

6. …extended to Cabling Management Concept extended to cover management of CMS cabling. (Frank Glege & Stephane Bally). Definition and visualisation of routings, generation of cutting lengths, approval of cable-types, attribution of labels, logging of installed cables. about 50k cables and routings entered in the database Several pragmatic features developed along the way eg -parallel user labels or TS cabling DB labels included in item record. - comprehensive scheme enabling any item or cable destination or routing to be assigned an intelligible visual label+barcode (AB + Ron Pintus) Labelling technology,linked to DB, is in daily use.

7. Incorporating features such as … 3D visualisation of cable routings and of connected equipment location Link from DB to EDMS for material composition as needed for INB, safety approvals, maintenance and test procedures etc

8. and also.. Possibility of planning and following installation or maintenance tasks using information in the database on equipment, locations, activity, routings (tool needed for planning interventions and minimising dose to personnel) Much work to be done to develop this fully

9. Towards a complete EMD CMS (S. Bally, D. Uzunova) now working (somewhat belatedly due to very limited manpower) to catch up with the original concept of applying the “rack wizard” concept to manage the configuration of detector and on-detector elements in an equipment management database, linked to 3-cD visualisation of objects and physical locations in the CMS as-built geometry. This forms part of the online suite of databases and satisfies INB traceability requirements automatically. Many useful tools in place…all needs driven. Pilot project with endcap muon CSC’s running. User feedback crucial. End-product MUST be user-friendly and there Must be a “reality check” mechanism Very close collaboration with IT to ensure architecture and application are consistent with CERN ORACLE strategy and practice.

10. Databases and INB: CMS comments Incomplete understanding of how to incorporate RP screening information in the database and how to interact with the legal waste management database maintained by SC-RP (frequent hand-off to ISRAM or only once object declared “waste”??) With a little work we could have a standard (expt + machine) RP screening station with barcode reader, RP data-capture into database etc….ATLAS farther advanced with this. Guaranteed availability, longevity and backup may be an issue. Proposed transfer to TS machine maintenance database (MTF) for archive was abandoned. (No convincing argument that this is really adds to the provisions from ORACLE support). For EMD to be effective for CMS users, need to deploy some technology trialled 3 years ago and already in use in ATLAS: “traceability/RP stations” with associated hardware and software: continue productive cross-experiment cooperation and coherence. Very short of resources for this,especially while installation still ongoing. Link of object history to radiation simulation and measurement maps not implemented yet for lack of manpower.

11. Conclusion INB is procedure- and paperwork- heavy and it will get worse. (“retour d’experience” etc) A properly implemented “online” EMD for management of the equipment configuration will, with a few extra additions, automatically satisfy INB traceability needs and save much collaboration effort later in the lifetime of the experiment. From Dec 05 LEAF meeting (AB): Resources for long-term operation as an INB will be considerable for the lifetime of the LHC and beyond - needs professional safety engineers, QA specialists, RP techs, DB experts, admin assistance… - as well as dedicated hardware and facilities (waste repository, screening system, dosimetry system) Common DB support and development (in PH dept, under the oversight and control of the experiments) for common features could be very cost effective. Start with a fellow or PJAS? Any support must be needs driven from the experiments.

12. ..more from presentation to LEAF 8 Dec 05 Worries for experiments are approximately unchanged for 4 years! Skilled resources for: zoning calculations, hazard analysis, waste/effluent studies, QA study + documentation. Practical implementation of: buffer zones, RP screening, database links, dosimetry to check activation assumptions. Long-term backup of Equipment Management Databases for traceability. Restrictions from indiv/collective dose limits and need to constantly improve. Maintenance and storage of ra materials in use or not yet classified as waste - need for workshops qualified for work on materials classed as radioactive - shipment off-site of equipment within ZDN or RP operational ra zones Long-term responsibility and costs of waste material classed as radioactive - displacement of detector support facilities in ISR Funding agencies will view INB provoked costs as a CERN responsibility Long-term personnel (central, PH & within experiments) for operation as INB. OK

13. more from presentation to LEAF 8 Dec 05 Estimates originally made for the DoR in 2002, simplified for INBIG report: This table should be re-evaluated over the coming months- emphasis somewhat changed, but It is hard to escape the conclusion that at least 0.5 FTE + 50-100k/yr per experiment will be needed from 07 - assuming there is properly staffed central support & coordination.