EAM Meters

  • Published on
    01-Nov-2015

  • View
    28

  • Download
    2

Embed Size (px)

DESCRIPTION

EAM_Meters.pdf

Transcript

<ul><li><p>Oracle Enterprise Asset </p><p>Management </p><p> Using Meters in EAM </p><p>An Oracle White Paper </p><p>Nov 2014 </p></li><li><p>Table of Contents </p><p>1. OVERVIEW .............................................................................................................................................................................................................................. 1 </p><p>2. WHAT ARE METERS ? ............................................................................................................................................................................................................ 1 </p><p>3. BASIC SETUPS FOR METERS ................................................................................................................................................................................................ 3 </p><p>4. EXAMPLE USES OF METERS ................................................................................................................................................................................................. 7 </p><p>5. APIS AND TABLES USED FOR METERS .............................................................................................................................................................................17 </p></li><li><p> 2 </p><p>1. OVERVIEW </p><p>The objectives of this white paper are to provide an overview of what meters are and how they are used in EAM. The paper will look at the setups required and look at some examples of using meters. There will also be a brief discussion of APIs and tables related to meters. The topics covered in the paper are : </p><p> What are meters? Basic Setups Some examples of using Meters Tables/APIs used for meters </p><p>2. WHAT ARE METERS ? </p><p>Meters are defined and associated with asset numbers to measure the assets </p><p>(or rebuildable items) usage. </p><p>Example : odometer, counter. </p><p>Meters are used in Preventative Maintenance Scheduling to schedule and generate work orders. Meter Readings are entered at Work Order Completion. Meter Readings can be mandatory or non-mandatory at this stage. However, Meter Readings are mandatory for work orders which are generated by PM Scheduling. </p><p> 3. BASIC SETUPS FOR METERS </p><p> The following setups are required to use Meters: </p><p> Create an asset </p><p> Create Activities: Meters are used to measure usage of an asset and the </p><p>main reason for doing this is to carry out maintenance work based on the </p><p>usage. Hence, one or more activities need to be defined for the work to </p><p>be done. BOMS and routings can also be created for the activity. </p><p> Create the meter </p><p> Associate the meter to the asset(s) </p></li><li><p> 3 </p><p> Now define the PM Schedules which will generate the work orders for the </p><p>designated activities based on the meter rules. </p><p>Lets now look at the setups in more detail before exploring some examples: </p><p>3.1 We have an asset DTF3000. Here is an activity : </p><p>3.2 : Next - here is the Maintenance BOM created for the activity : </p></li><li><p> 4 </p><p>3.3 : Here is the Maintenance Routing created for the activity : </p><p>3.4 : Now lets look at how this activity is associated to an asset using the </p><p>Activity Association form : </p></li><li><p> 5 </p><p>3.5 : There are 2 ways to create a meter : </p><p> Create a Meter Template and then instantiate them when creating </p><p>an asset </p><p> Create a Meter manually and then associate it to one or more </p><p>assets. </p><p>Meter Readings can be mandatory or non-mandatory at this stage. </p><p>Meter Readings are mandatory for work orders generated by PM </p><p>Scheduling. </p><p>3.5.1 Lets now look at how the meter is created using the manual method : </p><p>Here is the meter used for the previous activity and asset : (not all the values </p><p>are shown in the screenshot they are as follows: type = absolute ; UOM = </p><p>Ml ; value change= ascending ; initial reading = 120000 ; rate per day = 200 ; </p><p>no of past readings = 600) </p></li><li><p> 6 </p><p>Explanations of Key fields used in defining meters : </p><p> Meter Type : This can be either of the following: </p><p> - Absolute = actual readings used and value field enabled when </p><p>entering readings. </p><p> - Change incremental changes are measured. Change field is </p><p>enabled for meter readings. </p><p> Source Meter : For example when a parent asset meter is updated, it will </p><p>update the child asset meter readings also. Example : A truck meter is </p><p>updated. This updates the child transmission meter also. </p><p> Value Change: Controls the direction allowed for meter readings: </p><p> - Ascending = Readings can only go up (e.g car odometer) </p><p> - Descending = Readings can only go down (e.g a liquid dispenser </p><p>which starts full and then the liquid starts to get used and is </p><p>reduced) </p><p> - Fluctuating = Readings can go up or down (e.g a temperature </p><p>gauge) </p><p> Used in Scheduling Checkbox : Meter is used in PM Scheduling </p><p> Required Checkbox : meter readings are required when the work order is </p><p>completed for the associated asset. </p><p> Initial Reading : Automatically used as the first meter reading entered. </p><p> Rate : Works in conjunction with the no of past readings to calculate daily </p><p>meter usage estimates based on historical readings. </p><p> No of Past Readings : Dictates the number of readings prior the schedular </p><p>should go to calculate the usage rate. </p><p> Primary Failure Meter (PFM) : This is the default meter used for Failure </p><p>Analysis (optional). Failure Analysis not a part of this webcast separate topic. </p><p> The PFM is used to calculate meter based MTBF and MTTR </p><p> MTBF = Mean Time before Failure </p><p> MTTR = Mean Time to Repair </p></li><li><p> 7 </p><p>3.5.2 The other method of creating meters is to use a meter template. </p><p>The Steps are : </p><p> - Create meter template </p><p> - Assign it to an asset group. </p><p> - Create a new asset for that asset group </p><p> - A new meter instance will be automatically created for that </p><p>asset number. This is ideal for fleet management for example. </p><p> Next - the PM Schedule is created for the asset/activity/meter </p></li><li><p> 8 </p><p> This shows the last service date information: </p><p>Before I look at some examples I will highlight some points about usage rate </p><p>and number of past readings : </p><p>Lets say you specify the number of past readings on the meter definition as </p><p>10 and the usage rate as 25 miles a day. </p><p>If there are insufficient readings in the system for the meter - (e.g 9 rather then </p><p>required 10), the system uses the usage rate/day (25 per day) in the </p><p>calculation. </p><p>Otherwise, the system will use the historical readings to calculate the usage </p><p>rate which is stored on the PM Schedule. </p><p>A Tip : If you do not want the system to calculate the usage rate but use the </p><p>one you have provided, then use a very high value for no of past readings - eg </p><p>999999. After 1000000 readings, the system will recalculate the usage rate. </p><p>The new usage rate will be seen on the PM Schedule and will be based on your </p><p>latest meter reading and historical readings. </p><p>If you want to know the formula used by the PM Engine to forecast work </p><p>orders when using meters, refer to the note below : </p><p> Formula Used By Workbench To Forecast Work Orders (Doc ID 812166.1) </p><p> Another tip : Uncheck the flag 'Implement From Horizon Start Date if you </p><p>want the system to include past dates in the calculation and take into account </p><p>all potential work orders. </p></li><li><p> 9 </p><p>4 EXAMPLE USES OF METERS : </p><p>Now I will consider some example uses of Meters. </p><p>CASE 1 : </p><p> 1 meter assigned to multiple assets : </p><p> E.G : Test_Meter1 Assigned to Asset numbers ASSET1, ASSET2, ... Etc. </p><p> Readings are done on the meter. </p><p> When entering a value in the Meter Reading , the value becomes the last </p><p>value reading for all the assigned asset numbers. </p><p> Thus, entering a value for ASSET1 when completing a work order for </p><p>ASSET1 , will be seen as the last reading value for ASSET2. </p><p>CASE 2: </p><p> 1 meter - 1 asset : </p><p> E.G : TEST_METER_1 is assigned to one asset number , Asset1. </p><p> And TEST_METER_2 assigned to another asset number , Asset2. </p><p> In this case when you record a reading for Asset1, it will the last reading </p><p>value for the TEST_METER_1, thus not interfering with TEST_METER_2. </p><p> Each meter will have its own values and last value. </p><p> Hence, if you need to track readings by individual asset number, you must </p><p>assign the asset number its own specific meter. For example if you want </p><p>to track the service of 2 cars using the odometer, you will need a separate </p><p>meter for each car you cannot use one meter for both cars. </p></li><li><p> 10 </p><p>CASE 3 User wants to create a PM definition so that work orders are not </p><p>suggested until the meter reading (say 100) has been exceeded. Define a Meter with Rate per Day = 1 and Number of Past Reading = 9999 </p><p>99 Create a PM with Meter rules for every 100 hours as the Interval In the Scheduling Options: Use: Base Meter or Base Date to suggest Next </p><p>Service: Start Date EAM Parameters: Uncheck the flag 'Implement From Horizon Start Date'. Run the Forecasted Work from the Maintenance Workbench. CASE 4 : The User wants to generate work orders based on last service reading. Setups are as follows: Meter = Test_meter1. This was defined as base meter on PM Schedule with : Initial Interval = 1 Usage Rate = 5.249378 Base Interval = 100 Last Service Reading = 900 ; Date = 29-SEP-2010 13:20:35 On 10-Oct-2010 14:20:36, meter reading of 1000 entered. However : no work order was generated. Solution for Case 4 : Base Meter is mentioned with base meter reading as 1, so suggestions are forecasted from the base meter reading always - irrespective of last service reading. Base Meter reading=1, so PM forecasts work orders at following due readings as the interval is 100: 101, 201, 301, 401, 501, 601, 701, 801, 901, 1001 and so on. Usage rate=5.249378 Latest Meter reading=1000, latest meter reading date: 10-Oct-2010 14:20:36 User forecasted in horizon: 29-Sep-2010 to 30-Oct-2010 </p></li><li><p> 11 </p><p> Lets calculate when due reading 901 falls on: Left days = (Latest Meter reading-due reading)/usage rate = (1000-901)/5.249378 = 99/5.249378 </p><p> = 18.859377 Suggestion date = Latest Meter reading date +left days : </p><p> = 10-Oct-2010 14:20:36 + 18.859377 Suggestion Date = 29-OCT-10 Solution : Remove the base meter. Just use a meter rule in PM with scheduling option : Actual Start Date/Actual End Date/Schedule Start Date/Schedule End Date. CASE 5 : User wants to measure fuel usage for 1000 buses. </p><p> Possible solution: You can create a meter for each bus. There is no need to create any work order just enter meter readings for each bus periodically and then write your own reports to analyse the data. Use a change meter, with value type ascending and direction of Fluctuating. </p></li><li><p> 12 </p><p> CASE 6 : Can I assign 2 meters or more for 1 asset? For example , one is an odometer and the other is an hour meter to measure engine hours. Whichever comes first, the WO should be triggered. (WO to be created at 5000 KM or 2000 hours whichever comes first). This is possible because you can associate multiple meters to an asset number AND a PM schedule can have multiple meter rules. As an aside a PM schedule can have BOTH a date rule and a meter rule and the one which comes first will trigger the work order. In the multiple rules region, you can specify the value FIRST or LAST (for scheduling based on field) to deal with due dates (first or last due date of all rules). Lets look at an example of this : Rule 1 : Odometer - 5000 KM Rule 2 : 240 Hours Scheduling Based On : First Due Date Lets say the current meter is 4900 and will get to 5000 in 2 days : PM will generate WOs only for rule 1 as it is due in 2 days. If you suggest a </p><p>period longer or shorter, it is not relevant, only rule 1 will apply. WO for Rule 1 will be generated before rule 2 reaches its target. </p></li><li><p> 13 </p><p> After a period, the PM runs again. If at the next run, the 240 Hours rule comes first this time, then only rule 2 </p><p>will be used for the chosen period. Conversely, you can choose Last Due Date in the Scheduling Based On </p><p>region. In this case, even if rule 1 reaches its due reading, the service is not scheduled until rule 2 has also reached its due reading. </p><p>CASE 7 : Trucks of a specific Make and Model need to be scheduled for an oil change every 30 days, or every 1000 miles. Date Rule defined: - Last Service Start/End : Date December 26, 2001 - Interval In Days: 30 Meter Rule defined: - Last Service Reading 3000 - Interval 1000 - Latest Meter Reading 3100 (found within meter reading history) - Latest Meter Reading Date January 1, 2002 (this can be found via meter reading history) - Usage Rate 25 miles per day If the Meter Rule is taken into account, the next due date is February 6, 2002 </p><p> (January 1 2002 + [(3000 + 1000 - 3100)/25 = January 1, 2002] +36 days), and every 40 days after that. This is calculated as the interval (1000 miles) divided by the usage rate (25 miles per day). </p><p> The PM Scheduler process compares the above suggested dates from the runtime interval rule, to those of the date rule: Base Date of December 26, 2001 + every 30 days. The Work Orders ultimately created by the PM Scheduler process are those of the earliest or latest dates, depending on how the Schedule Based On region is populated. If you selected First Due, the earliest suggestion is used for Work Order creation. The opposite is also true if you selected last due. </p></li><li><p> 14 </p><p> CASE 8 : Use of the Intervals Per Cycle field. This field represents the number of base intervals that comprise the complete cycle. For example, 12 monthly intervals would comprise a 1-year cycle, and four 7,500 miles base intervals would comprise a 30,000-mile cycle. The group of maintenance activities on one PM schedule represents a cycle of activities. After the cycle of activities completes, the cycle restarts. For example, you can define a PM schedule for two activities that have a common Base Interval of 7,500 miles. The first activity is an oil change, and is scheduled every 7,500 miles. The second activity, a tune-up, is scheduled for every fourth interval or 30,000 miles. The work order for the oil change generates on each occurrence of the 7,500 mile interval and the work order for the tune-up generates on the fourth interval occurrence. CASE 9 : Multiple Activity Example: - Inspection every 100 hours of operation - Minor PM for every 200 hours of operation - Major PM for every 400 hours of operation - Scheduling Option: Base Meter </p></li><li><p> 15 </p><p> The above screenshot shows the PM schedule for this example. The screenshot below shows the forecasted work orders : </p><p> The program will update Current Cycle and Current Interval Count when </p><p>PM work orders are completed. For example at 210 hours of operation, two Inspection work orders and </p><p>one Minor PM work order have been generated and completed. The Current Interval Count has been updated to (2). The Curr...</p></li></ul>