Before submitting a request for work advisory, the ORM system needs to ensure that similar active work is not already in process. Once the ORM system submits a request for work and receives back a Work Request or Work Order unique identifier, the ORM may periodically want an update on the status of the work. Finally, the ORM system also needs to retrieve the work history of a functional location segment or asset to perform comprehensive equipment health diagnostics/prognostics.
Actors
| Maintenance Management System | Responds to queries on work requests and/or work orders for function location segments, serialized assets, or models along with status changes for this work and completed work histories for these entities. |
|---|---|
| Operational Risk Management System | Issues queries on the work requests and/or work orders for function location segments, serialized assets, or models along with status changes for this work and completed work histories for these entities. |
Triggers
The information flows can occur after the following events have occurred:
- Use Case 1 and Use Case 10 have resulted in the MMS and ORM being populated with functional location segment, serialized asset data with make/model information as well as measurement location “tags”.
Data Content
The data sent from the MMS to the ORM consists of:
- The functional location, serialized asset, or make/model where work is to be performed
- The work request or work order with associated work steps
- Work status audit trail records
- Completed work records
Data Formats
The data published by the ORM and received by the MMS must conform to MIMOSA CCOM BODs.
MIMOSA CCOM Reference Types
For the purposes of reference data management, the following MIMOSA CCOM types may be referenced:
- AgentType
- AssetType
- AttributeType
- ModelType
- PriorityLevelType
- SegmentType
- SolutionPackageType
- UnitType
- WorkManagementType
- WorkTaskType
MIMOSA CCOM Business Object Documents
The following MIMOSA CCOM BODs should be supported:
- GetWorkRequests
- ShowWorkRequests
- GetWorkOrders
- ShowWorkOrders
- GetWorkStatuses
- ShowWorkStatuses
- GetCompletedWork
- ShowCompletedWork
Infrastructural Components
ISBM
The communication between all systems occurs via the ISBM using request-response services.
Implementation Requirements
The MMS must implement a client for the ISBM Provider Request and Channel Management Services. The MMS may implement the ISBM Notify Listener Service for request notification.
The ORM must implement a client for the ISBM Consumer Request and Channel Management Services. The ORM may implement the ISBM Notify Listener Service for response notification.
Suggested Channel/Topic Configuration
A channel should be created for install requests and should conform to the following format:
/Enterprise/Enterprise Subdivision/.../ISO18435:D2.3
For example:
/Enterprise/Refinery A/Area A/Light Ends Area/ISO18435:D2.3
As outlined in the document ISBM Guidelines, topics should match the message content. Correspondingly, the following topic format should be used:
OIIE:SC15:V1.0/StandardXMLSchemaName{:Version}
For example:
OIIE:SC15:V1.0/CCOM:GetMonitoredEntityActiveWork:V1.0 OIIE:SC15:V1.0/CCOM:ShowMonitoredEntityActiveWork:V1.0 OIIE:SC15:V1.0/CCOM:GetWorkStatus:V1.0 OIIE:SC15:V1.0/CCOM:ShowWorkStatus:V1.0 OIIE:SC15:V1.0/CCOM:GetMonitoredEntityCompletedWork:V1.0 OIIE:SC15:V1.0/CCOM:ShowMonitoredEntityCompletedWork:V1.0
