Use Case Modelling for Risk Based Maintenance Management System

Qikai Zhuang, Dhiradj Djairam, Ravish P. Y. Mehairjan, Johan J. Smit High-voltage Technology and Management, EWI

Delft University of Technology Delft, the Netherlands q.zhuang@tudelft.nl

Abstract—Utility companies are shifting their maintenance strategies from corrective or time-based to risk based. Meanwhile, the asset datasets which support these strategies are being migrated from spreadsheets to databases. As a first necessary step of this migration, the authors analyzes the requirements from risk based maintenance strategies add to the maintenance management software systems, through extending the use cases of existing software products. The main contribution and characteristic of these extensions is to provide “flexible information sharing”, i.e. facilitate the growing demands to exchange asset data among stakeholders for the future development of asset management systems.

Keywords-risk based maintenance; maintenance management; asset management; use case; object-oriented development

I. INTRODUCTION

Maintenance management is the core business of asset management (AM)[1]. The methodology to direct and plan maintenance activities is called maintenance strategies[2].

Currently, the maintenance strategy is de facto time-based preventive in most transmission grids and corrective in most distribution grids. From the perspective of information management, a relatively small-scale asset dataset is sufficient to support these maintenance strategies.

This paper intends to investigate the requirements that evolvements of maintenance strategies impose on the asset datasets. In software engineering, this is regarded as the first step to develop a computer based maintenance management system[3]. The arrangement of this paper is as follows:

Information strategy of utility companies is composed of two parts – risk management and data management[4]. These two parts are reviewed respectively in Section II.A and B. From the review, we realize that: Today’s maintenance management systems are just offering primary support to condition based strategy. Within these systems, two functions are underbuilt: maintenance planning and scheduling.

Therefore, in Section III, we firstly modeled two functions with the use cases[3] and then recommend design patterns for critical part within the use cases. Finally, the conclusion is reached that: This model can realize a risk based maintenance management system, which is capable to share the asset data among a wide range of specialists within a utility company.

II. COMPUTER BASED MAINTENANCE MANAGEMENT

A. Maintenance Strategies In the last few decades, researchers have invented a large

number of maintenance strategies for industries in general, or for the utility sector in specific. The evolvement of maintenance strategies contains four major stages. They are:

1) Corrective maintenance (CM) As a maintenance strategy, CM is essentially leaving all

assets running till failure, and then replace it.

2) Preventive maintenance (PM)1

The primary upgrade from CM to PM is the maintenance plans and schedules. PM plans aim to describe the repair techniques which can efficiently improve reliability and availability of physical assets. Generally speaking, a PM plan consists of (1) repair technique(s), associated with failure mechanisms, (2) the standard repair procedure (3) a list of required resources (e.g. spare parts and labors).

The case that a PM is applied on an asset item is called a PM task. And the timeline of PM in an asset population is the PM schedule. Through applying PM schedules, resources can be arranged in advance, which considerably accelerates maintenance delivery and reduces the operational costs.

Traditionally, PM is scheduled with predetermined interval, called time based maintenance (TBM). The interval is decided according to asset type and fixed for asset lifecycle. Recently, the improvements on the scheduling methods give rise to the “predictive maintenance”.

3) Predictive maintenance In maintenance management, being predictive refers to

estimating the probability of potential failures on assets.

A “intermediately” predictive strategy is the TBM with its interval changed according to the failure rates predicted from historical failure statistics. This strategy can adapt maintenance frequency to changing operation environments within an asset lifecycle. But the difference of aging conditions between individual asset are still uninvestigated.

The “fully” predictive strategy commonly refers to condition based maintenance (CBM)[5]. In CBM, the health

1 The abbreviation PM refers to preventive maintenance in most literature and this paper as well.

J-3 2012 IEEE International Conference on Condition Monitoring and Diagnosis23-27 September 2012, Bali, Indonesia

978-1-4673-1018-5/12/$31.00 ©2012 IEEE 862

conditions of individual asset items are firstly diagnosed predictively. Then, PM tasks on different asset items of the same type are prioritized according to their health conditions.

The academia or the management world often believes that CBM is based on online condition monitoring. However, in engineering practice, applications of monitoring solutions are limited by their high demand on investment and knowledge. Periodic inspections and offline diagnostic tests remain the main approach to support condition diagnoses.

4) Risk based maintenance (RBM) A risk is composed of a probabilistically modeled stimulus

and its consequences. In the planning, the stimuli are the failure modes for RBM, which brings the term failure mode and effect analysis (FMEA). In scheduling of RBM, the potential failures on asset items are the stimuli, the same as CBM.

The probabilities of these stimuli are highly recommended to be estimated from health conditions derived from condition diagnosis. However, in practice, FMEA is mainly based on failure statistics. And a failure mode with low criticality will probably be maintained without condition diagnosis, or even correctively.

The consequences of failure modes and potential failures are measured with a number of performance indicators, such as customer minute loss, financial loss, safety, etc. These performance indicators connect operational-level maintenance tasks with high-level AM policies[6].

Decisions on PM plans or schedules are based on the risk register of failure modes or potential failures. Risk register is a process to rank multiplying product of probability and consequence. The term reliability centered maintenance (RCM) refers to the situation when maintenance schedule follows the ranking of risk register. In full RBM, the PM schedule ranks the sum of the risks of failures and cost of maintenance. Obviously, the risk based scheduling can be applied throughout the asset portfolio, instead of within asset category as CBM.

B. Data Management for Risk Based Maintenance Maintenance is frequently the last computerized department

within an industrial company[7]. Because of the long lifecycle, high reliability and limited population of high-voltage assets, the number of PM records is much smaller than the average level of other industrial applications, such as ICT and manufacturing. Consequently, spreadsheets seem to be sufficient solution for today’s asset manager.

However, the evolvement of maintenance strategies imposes additional requirements on the datasets, mainly in three aspects. Firstly, component failures are required to be linked with system interruptions, which changes the way to classify failures or assess reliability. Secondly, condition diagnosis introduce not only complicated decision making rules to the maintenance scheduling process, but also predictive information to the reliability and maintenance datasets. Thirdly, in RBM, the failure consequence needs to be evaluated with non-technical performance indicators.

The above three extensions respectively involves system reliability specialists, diagnosis technology specialists and commercial risk specialists in maintenance management.

Therefore, instead of being handled in a centralized way, future RBM datasets are likely to be managed and updated by a wide range of specialists. As a natural result, today’s solutions such as spreadsheets will become obsolete, because of their limited capability to be shared and updated within a large business organization. This give rise to the demand of a software which can facilitate distributed handling of RBM data.

Currently, multiple software products are available for maintenance management, but most of them cannot cover a complete range of the above stated issues. Generally speaking, products from the enterprise management world, such as IBM Maximo, tend to be complete in the resource planning module, but lack of functions for condition diagnosis and reliability engineering (i.e. dark grey area). On the contrary, products of engineering companies like ABB, are much more prepared on technical issues (e.g. testing, repair, condition diagnosis, switching etc.) than business issues (e.g. purchasing, inventory, contracting, human resource, etc.). Unfortunately, nearly no products can support the RBM until now, because the AM policies which decide the performance indicators for the complete corporation [6] are still under investigation by policy analyzers.

In this situation, we narrow the task of our modeling as: search for functions RBM added to PM, decompose them into essential procedures and describe them in a standard way for software engineers.

III. USE CASES IN RISK BASED MAINTENANCE

A. General Description of the Method A use case (i.e. a case in the use of the system) is way the

studied system interacting with “actors”, namely a user or an external system, in a number of steps. Originally introduced by Ivar Jacobson, use case is currently a mainstream way to capture the functional requirements on a software system in this early stages of developments[3]. Its main advantage is: Individual software developer can focus on one specific usage aspects of the system. This fits our purpose to focus on the extended part from PM to RBM.

The modeling of each use case is performed through describing 7 elements, as [3] recommended. They are: actors,functions, preconditions, invariants, basic course of actions,scenarios /alternative course of actions, postconditions.

The actors can be searched though studying the roles that asset owner, asset manager and service provider [2] play within maintenance management. With the evolvement from RBM to PM:

Asset owner are not only operating the network, but also maintaining relationship with stakeholders such as regulator and community, and developing strategies for long-term developments.

Asset manager are responsible now for budget control, risk management and reliability engineering.

Service providers are expected not only to deliver, but also to schedule maintenance tasks. In addition, the importance of technology specialists emerges, because they provide knowledge to support condition diagnosis.

863

TABLE I. ROLES IN PEVENTIVE AND RISK BASED MAITENANCE,MODELLED AS ACTORS IN USE CASES

Organization Roles in PM Additional Roles in RBM AssetOwner

Capital Investment Controller; Network Operator;

Stakeholder Relationship; AM Strategy Manager

AssetManager

Asset Portfolio Dataset; Maintenance Manager; Resource Manager;

Budget Controller; Risk Manager; Reliability Specialist;

ServiceProvider Maintenance Deliverer Maintenance Scheduler;

Technology Specialist;

The course of action is a series of numbered steps to finish a use case. In our modeling, the level of numbers shows the “use relationship”, i.e. the child action is used by the parent action. The shade color of the serial numbers shows the “extension relationship”: Actions in light grey are the extensions from PM to CBM, and those in dark grey are the extensions from CBM to RBM. Actors in italic in Table II and III implies that they communicates with the relevant actor(s) within each action. The above three underlined relationships are the standard elements to visualize a use case in diagram unified modeling language (UML).

The pre- and post- conditions refers to the input and output of the course of action. The invariants, highlighted in yellow when they are used in course of action, are supposed not to be changed within the whole course of action.

As introduced in Section II.A, the improvements of maintenance strategies are mainly reflected in maintenance planning and maintenance scheduling. Section B and C will perform requirement analysis on them respectively, through describing the 7 elements of use cases mentioned above.

B. Use Case: Maintenance Planning Function: Maintenance manager create/amend PM plans

to limit the total effects of failure modes on reliability, finance and other performance indicators.

Preconditions:(1) Asset portfolio dataset is ready. (2) Failure modes/mechanisms are identified and encoded by

technology specialists(3) Historical failure records are classified according to

encoded failure modes/mechanisms within dataset handled by reliability specialist.

(4) Risk manager is ready to interpret failure consequences and hazards of PM plans with performance indicators.

Invariants: (1) The risk matrix [5] for risk assessments (2) The AM strategies

TABLE II. COURSE OF ACTION OF USE CASE “MAINTENANCE PLANNING” FOR ACTOR “MAINTENANCE MANAGER”

No. Function the system performs and the relevant actors in italic 1 Identify failure modes 1.1 Specify target assets and asset systems from asset portfolio dataset1.2 Acquire relevant failure mechanisms from technology specialist1.3 Reliability specialist creates or amends failure modes 2 Reliability specialist perform FMEA 2.1 Estimate the occurrence index 2.1.1 Acquire the historical records of component failure 2.1.2 Acquire the service life data of the target asset population from asset

portfolio dataset2.1.3 Acquire the condition indices of (a subpopulation of) the target asset

population from technology specialist2.1.4 Estimate the failure rate within the target asset population and

calculate the occurrence index 2.2 Estimate the severity index 2.2.1 Acquire records of system failure from network operator2.2.2 Calculate the ratio of system failure caused by a failure mode and

derive the severity index from it 3 Maintenance Manager develops PM plans 3.1 Generate or amend PM procedure in PM plan 3.1.1 Technology specialist collects/amends methods to prevent the failures 3.1.2 Technology specialist collects/amends methods to detect and diagnose

potential failures3.1.3 Technology specialist suggests the likelihood that the diagnosis

method can detect the failure mode (i.e. detection index of FMEA)3.1.4 Technology specialist suggests and reliability specialist reviews

typical frequency to implement the PM plan 3.2 Assess risks of implementing this PM plan with risk manager.

Include countermeasures in the PM procedure, if applicable. 3.3 List the required resources and outage duration required by the PM

procedure with resource manager and network operator. Examine feasibility of PM procedures through checking the availability of these resources.

3.4 Identify non-technical constraints to apply this PM plan in a PM task at a specific location, time etc. with AM Strategy manager

4 Make decision on PM plans 4.1 Assess failure mode in a risk matrix provided by risk manager4.2 Estimate costs of PM plans with resource manager4.3 Calculate profits of PM plans through subtracting its cost from the

risks it prevents. Select PM plans with highest profits. 4.4 Ask for approval from capital investment controller

Scenarios/alternative course of actions:(1) In PM, the course of action only contains the white area in

Table II. In CBM, the course of action contains the white and light grey area.

(2) Instead of updating the failure mode in Action 1, maintenance manager can acquire a list of failure modes directly from reliability specialist.

(3) Action 2.1.1, 2.1.2 and 2.1.3 are alternative conditions for Action 2.1.4.

(4) Action 3.2 and 3.5 are optional, depending on AM policies (5) In case of RCM, Action 4.2 is not applied. The decision in

4 will be moved between Action 2.2.2 and 3, which suggests that the maintenance costs are negligible or not considered.

Postconditions: the PM plan with its risk and cost optimized for performance indicators.

C. Use Case: Maintenance Scheduling Function: Maintenance scheduler determine when to

implement PM plans on which asset items, and ensure readiness of resources at the moment of implementation.

Preconditions:(1) The date of the next maintenance scheduling is given. (2) Asset portfolio dataset is ready. (3) Failure modes are known by technology specialists(4) PM plans are made by maintenance manager(5) Risk manager is ready to interpret failure consequences

with performance indicators.

Invariants: (1) The algorithms for condition and reliability assessment

864

(2) The PM plans, including the knowledge rules to associate them with failure modes, and their required resources

(3) The risk matrix for risk assessments

TABLE III. COURSE OF ACTION FOR USE CASE “MAINTENANCE SCHEDULING” FOR ACTOR “MAITENANCE SCHEDULER”

No. Function the system performs and the relevant actors in italic1 Acquire a complete list of relevant assets and PM plans (e.g. in

transformers) from asset portfolio dataset and maintenance manager2 Assess conditions of the assets 2.1 Acquire the service life data the target asset population from asset

portfolio dataset2.2 Acquire the maintenance history from maintenance deliverer and

calculate the period between last maintenance for each asset item 2.3 Acquire the condition indices of the target asset population from

technology specialist2.4 Predict the failure probability of each component (asset item) for the

upcoming period until the next scheduling, with algorithms developed by technology specialist

2.5 Deduce the probability of system interruption from the component failure probability, with algorithms developed by reliability specialist

3 Search for scenarios of PM tasks 3.1 Find PM plans capable to prevent the potential failure investigated in

2.4 and 2.5 with knowledge rules ready at maintenance manager3.2 Specify the PM plans as PM tasks through associate it with the target

component at a specific location 3.3 Search for feasible dates to implement the PM plans 3.3.1 Check availability of the spare parts and labor with resource manager

and maintenance deliverer3.3.2 Check availability of outages with network operator3.3.3 Apply for permission through stakeholder relationship manager 4 Make decision on PM schedule 4.1 Decide the probabilities of component failure and system interruption

for different scenarios of PM tasks 4.2 Assess potential failures in the risk matrix provided by risk manager

for different scenarios of PM tasks 4.3 Calculate exact cost of implementing each PM task at a certain time

and location with resource manager4.4 Calculate profits of different scenarios of PM tasks through

subtracting its cost from the risks it prevents. Select scenarios of PM tasks with highest profits.

4.5 Make PM schedules 4.6 Ask for approval from budget controller4.6 Generate work orders to maintenance deliverer

Scenarios/alternative course of actions: (1) The actions numbered in dark grey can be skipped in CBM. (2) In CBM and RBM, Action 2.1 and 2.2 are supplements to

Action 2.3, and hence, optional. (3) Action 3.3.3 varies according to AM strategies(4) In CBM and RCM, Action 4.3 and 4.4 will be removed.

And Action 4.1, 4.2 will between Action 2.5 and 3. It means that maintenance costs are neglected, and different scenarios of PM tasks don’t change failure risks.

D. Recommendations for further software design Several recommendations are listed below for further

design of a RBM system. Some of them are described in brief though mentioning their “design patterns”[8].

Firstly, the operational level of RBM shares a large number of functions with PM. A RBM system should reuse typical use cases of PM which deal with contracts, purchasing, inventories, human resources and multisite assets. The objects modeled in our use cases, such as PM plans, PM schedule, PM tasks and work order, have their counterparts in existing products reviewed in II.B.

Secondly, the transition from PM to RBM takes decades. During this period, the maintenance strategy is normally a hybrid of RBM, CBM, TBM and even CM. Therefore, we model the planning and scheduling as two “flexible” use cases fitting different maintenance strategies. The flexibility is reflected in the scenarios of both use cases, as well as the grey shades in Table II and III. In the design stage, the “strategy design pattern” can be applied to realize the courses of actions. As a result, the use case can shift easily to the alternative course of actions to adapt to different strategies.

Thirdly, in the design stage, it is important to consider more flexibility several more cases, such as:

(1) Add new failure modes or split/merge/redefine existing failure modes, without changing the PM plans. Solution: model failure modes with “state pattern”

(2) Integrate a number of condition diagnosis approaches with different knowledge rules or even condition indexing. Solution: apply “adapter pattern” to make different condition indexing complying with each other

(3) Allow policy makers to change risk matrix without disturbing maintenance management Solution: apply “strategy pattern” to the course of actions in sub use case “risk assessment” (e.g. 4.1 in Table II and 4.2 in Table III); use “observer pattern” , model the risk matrix as the subject and PM plans/schedule as the observer and get the decided PM plans/schedule updated.

IV. CONCLUSIONS

Maintenance strategies is evolving from corrective, to preventive and risk-based. The importance of software tools emerges with risk-based maintenance strategies are applied.

In this paper, we firstly point out that the main improvement in the process is in the planning and scheduling process. Then, to realize these two processes in software, we model them with use cases. Within the modeling, the focus is to keep the RBM use case compatible with PM, so that the transition from PM data to RBM data can finished smoothly. Finally, a brief discussion was performed, regarding the design patterns which can provide the use case with more flexibility and compatibility in changes of AM business in long term.

[1] Asset Management - an anatomy, version 1: The Institute of Asset Management, 2011.

[2] "Asset Management of Transmission Systems and Associated Cigré Activities," CIGRE Technical Brochure 309, 2006.

[3] I. Jacobson, M. Christerson, P. Jonsson, and G. Overgarrd, Object-Oriented Software Engineering - A Use Case Driven Approach:Addison-Wesley, 1992.

[4] "IT Strategies for Asset Management of Substations - General principles (final draft)," Cigré Technical Brochure, 2012.

[5] "Transmission Asset Risk Management," CIGRE Technical Brochure 422, 2010.

[6] PAS 55-1: Asset Management, Part 1: Specification for the optimized management of physical assets: British Standards Institution, 2008.

[7] J. Levitt, Managing Factory Maintenance, 2nd edition: Industrial Press, 2005.

[8] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software Addison-Wesley 1994.

865