The ST division manages and therefore maintains the CERN technical installations. A maintenance database application exists for every technical domain. A total of six different databases were built during the last 10 years and are based on the RAPIER maintenance program. As the Computerized Asset Management and Maintenance Systems (CAMMS) technology has evolved, the RAPIER system has become obsolete. Therefore we are forced to migrate to its latest version, MP5, before the year 2000. The migration path must be defined, leading from the current situation to a fully operational MP5 application. The major elements of each migration path consist in determining the functionality to use, defining the operation of it, adapting and/or creating procedures, converting data and providing training. A migration is always a process of change. The migration presents a unique opportunity to evaluate the current implementations, adapt them to the requirements and exploit the new features offered. Obsolete data and inconsistencies will be removed and the errors corrected

Sánchez-Corral, E

CERN Document Server

EUROPEAN LABORATORY FOR PARTICLE PHYSICSLABORATOIRE EUROPEEN POUR LA PHYSIQUE DES PARTICULESPresented at the 2nd ST WorkshopChamonix, France, February 2 - 5, 1999CERN-ST-99-015February, 1999COMPUTERIZED ASSET MANAGEMENT ANDMAINTENANCE SYSTEMS IN STE. Sánchez-CorralAbstractThe ST division manages and therefore maintains the CERN technical installations. Amaintenance database application exists for every technical domain. A total of six differentdatabases were built during the last 10 years and are based on the RAPIER maintenanceprogram. As the Computerized Asset Management and Maintenance Systems (CAMMS)technology has evolved, the RAPIER system has become obsolete. Therefore we are forced tomigrate to its latest version, MP5, before the year 2000. The migration path must be defined,leading from the current situation to a fully operational MP5 application. The major elementsof each migration path consist in determining the functionality to use, defining the operationof it, adapting and/or creating procedures, converting data and providing training. Amigration is always a process of change. The migration presents a unique opportunity toevaluate the current implementations, adapt them to the requirements and exploit the newfeatures offered. Obsolete data and inconsistencies will be removed and the errors corrected.21 INTRODUCTIONThe ST division manages and therefore maintains the CERN technical installations.There is a maintenance database-application (running RAPIER R4 product) in every technicaldomain of the division, i.e. Cooling and Ventilation for Accelerators and Sites, CERNPatrimony Civil Engineering, Telecommunications, Access Control, Personnel Safety, HeavyHandling and Transport, Power Suppliers and Electricity for Accelerators and Sites. Manypeople in the division work on the maintenance of the installations and most of us are directlyor indirectly concerned with it.The Computerized Asset Management and Maintenance System (CAMMS) technologyhas evolved a lot and now is the moment to move to this new technology. For this, it is firstnecessary to redefine needs, clean up all the ST Maintenance Technical Installationsdatabases and redefine the maintenance procedures. The new product, MP5, has to be inproduction for the end of 1999, so we have to make up our minds and hurry up! Themigration to the new product is a difficult process: It requires the participation of manydifferent people, working hard and carefully. A divisional project has been defined for thatpurpose. A common divisional strategy seems mandatory, not only for the migration processbut also especially in the future for applying a unique and standard maintenance in all thegroups.2 MIGRATION PROCESSIn general, for all the installations of MP5 a migration path must be defined, leadingfrom the current situation to the desired one of a fully operational MP5 system. Eachmigration path contains some general elements like training, determining which functions touse and how, adapting and/or creating procedures, and also data conversion if certain (basic)data exist in an electronic format.A migration is always a process of change of which the impact on the organizationdepends on the differences between the existing and the new situation. The impact could berelatively small if the existing situation is a previous release of MP5 and could be enormous ifthe existing situation does not involve a computerized maintenance at all. Somewhere inbetween these two extremes is the migration to MP5 starting from an old RAPIER V4Irelease, which is our case, and which will be discussed in detail below.2.1 The migration to MP5 involving a conversion from RAPIER 4Although MP5 has been based on RAPIER V4I.20, the migration to MP5 should not beunderestimated. The navigation has been completely redesigned, and the functionality hasbeen enhanced significantly. Which functions to use and how are still questions to beanswered.Also, many years of using and developing RAPIER resulted in a unique database,which could contribute greatly to the added value of MP5, although not necessarily byconverting all data in the R4 database as straightforwardly as possible. In fact the migration toMP5 presents a unique opportunity to evaluate the current implementation and adapt it to thecurrent requirements and the new possibilities offered by MP5. Obsolete data can beremoved, errors corrected and inconsistencies removed. In this light, the conversion path must3be seen as a starting point, which should be adapted to the customer's need for an optimalresult. The data conversion can then form an integral part of the total migration process.3 MIGRATION PREPARATION PHASEThis section presents the steps to be followed in a migration to MP5, see Refs. [1]–[2].Only the steps which require a special effort and involve the collaboration of different groupsare discussed in detail.In a first phase the following steps are identified:1) Clean up of the current database,2) General Information set-up in MP5,3) Definition of Asset’s basic data,4) Definition of Stores’ basic data,5) Definition of Work’s basic data,6) RAPIER data conversion and migration (when possible, for steps 2–5),7) History migration.3.1 Clean up of the current databaseRAPIER version 4 was originally an Oracle V5, SQL*Forms 2.0 application.Subsequent releases have been adapted to Oracle V6 and Forms 3.0 but inherited the technicallimitations of the original.  Of importance here, and one of the fundamental differences withthe new Oracle 7 based MP5 is the increased level of consistency checking in the database. InMP5 most, if not all, dependencies that exist between tables and columns are explicitlyenforced by means of database constraints. In R4 only two types of constraints have beenenforced:• primary key (through the definition of a unique index for each table) at table level• not null, at column level. All other dependencies and restrictions were taken care of in the RAPIER applicationitself. This gave ample opportunity to ‘correct’ most unwanted results of a premature commitusing the Oracle tool SQL*Plus. As a result of these corrections and (occasionally) bugs inRAPIER functions or previous conversions, the existence of orphans (child records of whichthe parent has been deleted), strange values and funny code is not unlikely and the number ofinconsistencies is expected to increase with the age of the database. Therefore it has been decided that all known inconsistencies, i.e. all the inconsistenciesthat will violate an MP5 constraint if converted without correction, and a number of others,must be corrected prior to the actual data conversion. To this purpose, R4 database ismonitored for suspected inconsistencies and listings of all detected inconsistencies areproduced. Corrections must then be carried out using the R4 functions or, more likely,SQL*Plus, according to the customer's requirements: In the case of ‘orphan’ records thecustomer may decide to remove the orphan, to nullify the reference, or to add the missingparent. The removal of one record may itself create new orphans: Monitoring and correctinginconsistencies is an iterative process which must be repeated until the last monitoring runyields no further inconsistencies.4  3.2 Definition of MP5 data MP5 General Information, Asset’s basic data, Stores’ basic data, and Work’s basic datahave to be defined by each service following the guidelines given by the ST MaintenanceProject Working Group. The process should be the following: • define new needs,• study current implementation in order to identify obsolete elements (mark them asnot to be considered for the migration)  and still valid elements which might have tobe converted to map the new needs,• define new needs not solved with any valid element existing in the old system,• prepare a Migration Specifications document containing the results of the abovestudy,• present the Migration Specifications document to the ST Maintenance ProjectWorking Group for approval.4 MAINTENANCE SYSTEMS IN STIn ST division there exist a total of six RAPIER maintenance databases plus oneCOSWIN database (HM group). An overview of the dimension of each database in terms ofnumber of main type of objects (equipment, systems, classes, routines, stock, users) and typeof maintenance done are presented respectively in Table 1 and Table 2.Table 1Overview of ST Technical Installations Maintenance databases: objects managedTechnicalInstallationNo.EquipmentNo.SystemsNo.ClassesNo.RoutinesStockarticleNo.UsersCoolingVentilation36290 91 211 883 17003 12CivilEngineering- 17 13 - - 14Electricity 91504 11 177 100 - 70Monitoringand Control19488 111 55 615 - 50HeavyHandling2800 22 7 1300 17600 145Table 2Overview of ST Technical Installations Maintenance databases: type of interventionsTechnicalInstallationPreventiveMaintenanceConditionalMaintenanceCorrectiveMaintenanceImprovementCoolingVentilationX X X XCivilEngineeringXElectricity X X X XMonitoringand ControlX XHeavyHandlingX X X5 STRATEGY PLANNING5.1 StrategyA divisional strategy has been defined; we can summarize its main points as follows.1) CERN-wide databases are used: personnel, budget codes, currencies, suppliers, stores.2) ST-wide databases are used: CERN Patrimony.3) The LHC Naming convention has to be followed for the codification of objects. Thisconsists in beginning with the letter/s assigned for the System/Subsystem to which theobjects belong. In ST we have decided to go further in the application of the LHC Namingconvention and apply it not only to the objects (maintained) but also to other mainelements of the system.4) The ST Maintenance Working Group should define, for all of ST divisioon, standardsconcerning the following elements:• job type;• job status;• procedures (divisional, group) where the different sequences of actions duringinterventions are specified;• job card;• criteria for retrieving information concerning the interventions;• safety permits;• conditions for interventions (shutdown machines, etc.);• job priorities;• requirement, action, cause and failure codes;• performance indicators.The objective is to define a common way of doing maintenance, based on a standard setof maintenance procedures, a common language, and supported by a unique CAMMS.65.2 Planning• Study and definition of the Migration Specifications document, to be done inparallel in all the groups (see Ref. [2]).• Pilot project with the Telecom service. The aim is to prepare and test the migrationprocess tools and programs, get experience and test the MP5 product itself, andevaluate the support and training given by the MP5 vendor. This is foreseen for theend of February and the training is scheduled for the middle of February.• The first MP5 training session is addressed to the Telecom team plus all the STMaintenance Managers.• As soon as the pilot project is in production and validated, start the migration of theother services.AcknowledgementsI wish to thank P. Martel, responsible for RAPIER and MP5 at CERN, who isdedicating part of his time to the ST migration databases, and the ST/MC group who havebeen working hard to prepare the specifications for the migration to MP5. I would like tomention specially the work done by the Telecom team and I. Bejar who has helped a lot inwriting the final Telecom Specifications document.References[1] User's Guide: MP5 Version 5.4, Datastream Sysems, Inc.[2] Pedro Martel (EST/ISS) and Eva Sánchez-Corral (ST/DI), Rapier DB MigrationProcedure to MP5. ST Division RAPIER Migration Process (draft).Presented to ST Maintenance Working Group 11/12/98. 

Computerized asset management and maintenance systems in ST

Abstract

Similar works

Full text

Available Versions

CERN Document Server