This Use Case describes the process for the triggering of maintenance work based on the condition of a functional location segment or serialized asset. Measurements from measurement locations or tags originate from a condition monitoring system (CMS) or an operational process control system or data historian (CONTROL). These measurements are then processed by an operational risk management (ORM) system, such as an Asset Health Management System (AHMS), which analyzes the condition data to generate an actionable condition-based maintenance (CBM) Request for Work to be sent to a maintenance management system (MMS), optionally with a desired pre-defined Solution Package, or pre-planned work order.

Background

The benefits of interoperability start to pay significant dividends when the near-real time decision support systems (such as ORM) begin to properly interact with the transaction processing oriented business systems (such as EAM) based on data/information feeds from true real-time systems involved in monitoring and control. While it is fairly easy to show a hierarchy of data/information/knowledge on a PowerPoint slide, the nature of the use cases needs to be fully contemplated when the transforms are taking place as part of the systems interaction scenarios. This involves several categories of systems spanning three basic layers (real-time, near real-time and transaction processing) in the interoperability stack and they are normally provided by several communities of solutions providers, with multiple vendors in each community. Providing sustainable interoperability for all of these systems of systems is a critical focal-point for open standards based interoperability.

This use case does not assume interaction with operations planning and scheduling oriented systems. It is limited to the current practice where specialized condition monitoring, asset health, reliability, quality and safety systems are able to diagnose or prognose a need for a maintenance action. When an ORM system (PSMS, AHMS, QMS, EMS) determines that a maintenance action is required; it must be able to generate a CBM-driven request for action/work advisories with an optional pre-planned solution package (sometimes called a “pre-planned work order”) using an open interface to an EAM system. The ORM should be smart enough to check beforehand to see if similar maintenance work entries are outstanding on an asset so as not to “flood” an EAM system with the exact same CBM request for action/work. In addition, the ORM system needs to be able to check the status of the work submitted.

Scope

The scope of this use case is limited to remove and replace corrective maintenance.

Preconditions

This Use Case is predicated on Use Case 1 and Use Case 10 occurring prior so that the Control System, Operational Risk Management System and Maintenance Management System are populated with functional location and equipment asset information.

Successful End Condition

Rectification work has been undertaken to remedy a (potential) equipment failure and process is ready for startup.

Actors

Business Actors

  • Maintenance Supervisor
  • Maintenance Planner
  • Technician

System Actors

  • Control System
  • Operational Risk Management System
  • Maintenance Management System

Triggers

Detection of incipient failure by control system.

Main Success Scenario

Detect failure and request work The ORM instigates the exchange via Use Case 7, Scenario 14 using the ProcessMonitoredEntityRequestForWork BOD. This will indicate that a particular equipment is about to/has failed and a Request For Work is sent.
Receive work request The MMS will receive the Request For Work from the ORM and respond with an official Work Request using the corresponding AcknowledgeMonitoredEntityRequestForWork BOD.
Optional Open filtered subscription session The ORM can open a new subscription session on the ISBM
to detect any new Work Order/s for the recently received Work Request. This is done via ISBM XPath filtering and specifying the Work Request ID previously received. The purpose of the new ISBM session is to not overload the ORM by receiving every single new work order, but only to be notified of relevant ones.
Create and publish work order At a later point in time, an maintenance planner/scheduler will
create a work order/s based on the Work Request (and maybe other work requests). The MMS will publish the creation of the Work Order via Use Case 7, Scenario 16 using the SyncMonitoredEntityActiveWork BOD. The Work Order/s will have ID references to corresponding Work Request/s.
Receive and record work order The ORM receives the newly created Work Order through the filtered subscription or by matching the Work Request ID. The ORM records the Work Order ID.
Optional Open filtered subscription session The ORM can open a new subscription session on the ISBM
to detect when the particular Work Order is set to a “Closed” status via an XPath filter.
Note This “Closed” status is a special, agreed-upon reference data
WorkAuditType between the MMS and other O&M systems. It will likely need to be a configuration option by an application, and may be in the majority of cases (but not necessarily depending on how an enterprise wants to structure their RDL) the MIMOSA CCOM Reference Data “Closed” WorkAuditType.
Field work and work order status change Field work results in status changes of the work order. The MMS publishes the Status change via Use Case 7, Scenario 16 using the SyncWorkStatus BOD.
Close work order When the ORM detects that the Work Order status is set to
“Closed” (either through XPath filtered subscription or matching the Work Order ID), the ORM can indicate that the equipment is ready to be brought online.

System Interoperability Scenarios