Maximo

Maximo

Come for answers, stay for best practices. All we're missing is you.

 View Only

  • 1.  Logic behind scheduled PMs?

    Posted 05/18/21 09:27 AM
    Edited by System Admin 03/22/23 11:46 AM
    MAM 7.6.1.2:

    I'm trying to understand the how scheduled PMs work in Maximo.

    For testing purposes, I've scheduled PMs for each hour of the day -- generating large WO hierarchies (from routes --> child WOs). There aren't any tasks in this test.






    And I have a query that I'm using to analyze the PMs and their resulting WOs:

    p = source is parent WO records
    pm = source is PM records
    c = source is child WO records


    I've made some observations based on that query:

    1. The PMs get run one-at-at-time; they don't run simultaneously.
    • If we look at columns C_MIN_REPORTDATE and C_MAX_REPORTDATE, then we can see that the PMs are run in a sequence: 12:33 AM to 3:19 AM, 3:20 AM to 5:46 AM, 5:47 AM to 7:55 AM, etc.
    2. The PMs don't run in any sort of intuitive order. I would have thought they would run in order of Target Start Time. But that doesn't seem to be the case.
    • Refer to the PM_TARGETSTARTTIME field in the query.
    3. Maximo isn't able to keep up with the PMs in this test. It ought to be creating 24 WO hierarchies each day -- one for each PM. But it runs out of time each day and only ends up generating 10-15 WO hierarchies, not 24.
    • The test tells me: if Maximo isn't able to generate all the PMs / WO hierarchies that were scheduled for the day, then it simply gives up on the ones it missed and moves on to the PMs that are scheduled for the next day.
    4. When I originally created the PMs, the Estimated Next Due Date field was the same for each of the 24 PMs. However, as mentioned in number 3, Maximo wasn't able to keep up, and the Estimated Next Due Dates quickly became out-of-sync among the PMs. This was counterintuitive to me and has made the PMs confusing to manage.

    Edit:
    5. If the PM gets interrupted for some reason (due to an error in Maximo, a server or DB outage, etc.), then the PM that is currently running stops, and the child WOs stop being generated for that PM.
    • As a result, there are child WOs missing, but no one would ever know. There isn't a mechanism in Maximo to notify MAXADMIN that there was a problem with the scheduled PM (issue needs to be investigated).
    6. Note: I'm aware that this test is extreme; it generates tens of thousands of WOs each day. The original purpose of this test was to generate PMs / WOs all day, every day, to help troubleshoot number 5 above.
    • If we have PMs / WOs being generated all day, then we can easily query for missing child WOs, and then investigate the timestamp of the last successful child WO for that PM (see the C_MAX_REPORTDATE column in the query above). We can look at the system logs at that timestamp and determine why the PM failed.
    • In other words, the test isn't a real-world scenario. But instead, it has helped me learn about how PMs work and highlight the issues mentioned above.


    Question:

    I'm new to PMs. I've likely misunderstood some of the things I observed above.
    Would someone be able to provide some insight about the logic behind PMs? Is there a reason behind some of the unexpected behaviors I observed?

    Thanks.


    #Maximo
    #AssetandFacilitiesManagement


  • 2.  RE: Logic behind scheduled PMs?

    Posted 05/18/21 10:08 AM
    Edited by System Admin 03/22/23 11:48 AM

    For reference, here's the query that I used:

    (and Craig Kokay provided an alternative query here.)

    --p =  source is parent WO records
--pm = source is PM records
--c =  source is child  WO records
select
    to_char(p.reportdate, 'MONTH DD') as p_reportdate_day,
    p.wonum             as p_wonum,
    p.pmnum             as p_pmnum,
    p.route             as p_route,
    p.reportdate        as p_reportdate,

--    pm.pmcounter        as pm_counter,
    pm.targstarttime    as pm_targstarttime,
--    pm.nextdate         as pm_nextdate, 

    c.parent            as c_parent,
    c.pmnum             as c_pmnum,
    c.route             as c_route,
    c.wo_count          as c_wo_count,
    c.min_reportdate    as c_min_reportdate,
    c.max_reportdate    as c_max_reportdate,
    c.processing_time_hrs as c_processing_time_hrs
from
    (select * from maximo.workorder where pmnum like 'BC%' and reportedby = 'MAXADMIN' and istask = 0) p
left join
    maximo.pm pm
    on p.pmnum = pm.pmnum 
left join
    (
    select
        parent as parent,
        pmnum as pmnum,
        route as route,
        max(reportedby) as max_reportedby,
        count(*) as wo_count,
        min(reportdate) as min_reportdate,
        max(reportdate) as max_reportdate,
        round((max(reportdate) - min(reportdate))  * 24,1) as processing_time_hrs
    from
        maximo.workorder
        where
            istask = 0
    group by
        parent,
        pmnum,
        route,
        changeby
    order by
        min_reportdate desc
    ) c
    on p.wonum = c.parent
order by
    p.reportdate desc







  • 3.  RE: Logic behind scheduled PMs?

    Posted 05/19/21 08:42 AM

    There is no "order" to generating the PMs.  A couple of things to keep in mind:

    1. Each route stop will become a work order and each task of the associated job plans will become a work order.  That means you are creating 40k work orders for the route stops alone.  Add 10 tasks each and that will be over 400k.
    2. In the organization app, you can use a where clause to filter which get processed.  For example, you can process records with a next due date that is less than or equal today.
    There is no parallel processing out of the box, and having two identical instances of the cron task running can cause problems.  However, it is possible to set up multiple users such that each user has access to a non-overlapping subset of the PMs (say by site or some other indicator - which could be a custom field such as the user name).  You can then set the run-as-user field of a series of instances to be each of those users and therefore safely run in parallel.

    ------------------------------
    Steve Hauptman
    ------------------------------

    Original Message


  • 4.  RE: Logic behind scheduled PMs?

    Posted 05/20/21 01:45 AM
    I don't recommend Steve's comment "For example, you can process records with a next due date that is less than or equal today."  Far too complicated.  I recommend that in the Organization setting for the PM to always use zero (0) days forward and to only select Active PM's, then to assign in each PM the Lead to be the actual number of days in advance for the targetted start dates (this gives you lots of flex), and then to have the PMWoGenCronTask to run once a day.

    You (if needed) to have multiple instances of the PMWoGenCronTask. Each running at different times to distribute the load.  You will need to ensure that the instance_pm_sqlwhere does not have PM's crossing over each other i.e. Area A,  Area B,  Area A + B, Area C, in this instance having Area A + B is bad, though noting other comments, even if you do, you will not generate the PM twice.  It loads up the server.

    ------------------------------
    ===============================
    Craig Kokay,
    Lead Senior Maximo/IoT Consultant
    ISW
    Sydney, NSW, Australia
    Ph: 0411-682-040
    =================================
    #IBMChampion2021
    ------------------------------

    Original Message


  • 5.  RE: Logic behind scheduled PMs?

    Posted 05/19/21 10:40 AM
    IN addition to what Steve H. says, it is helpful to keep in mind that in Maximo a PM is nothin more and nothing less than a schedule of events.  Your compressed "schedule of events" is likely causing you some confusion.  IN your test scenario you are running the same route everyday and increasing hourly "rounds".  This is non-sensical.  Your sidewalk inspection route is not executed with that type of "moving" schedule.  Each Asset or Location or Route is likely to have on a single or maybe double schedule to execute work.  Since PM's can be time based or "meter" based, for some Assets/Location you will likely have two PM schedules.  In either case, in your scenario you have skipped over a very important part of the job planning process.  What do you Job Plans look like?  in your story telling you skipped right over that chapter.  The routes are tied to the Job plan and the Job plan IS the event. Think back to your vehicle and your 3 month 3,000 mile oil change.  6 month / 6,000 mile oil change and tire rotation, etc.  The classic car maintenance schedule with all the various activities are the various job plans the time cycle is the schedule.

    In your case you sidewalk inspections may or may not be the same job plan (i.e. with the same route and tasks.) you may or may not change the route and / or tasks. but it is important to keep that in mind as part of your a) story telling here and b) understanding of how the PM cycle works. You ha e several really good questions and observations but I believe that your test is a) unrealistic and b) quite likely caused memory faults on the JVM and may very well have caused the cron jobs to error with out of memory issues.  You state that not all WO's were created. Your words:
    • The test tells me: if Maximo isn't able to generate all the PMs / WO hierarchies that were scheduled for the day, then it simply gives up on the ones it missed and moves on to the PMs that are scheduled for the next day.
    Maximo just doesn't "give-up".  It is not a human that gets bored and decides to go play some where else.  What do your logs say? How is your dev system configured? do you have a properly set up Dev instance to handle the kind of stress /load you are putting on it (i.e. multiple JVMs properly sized memory, etc.)?

    ------------------------------
    Bradley K. Downing , MBA
    IBM Certified Adv. Deployment Prof. Maximo v7.6.1
    IBM
    ------------------------------



Related Content