3rd International IEEE Conference Intelligent Systems, September 2006

Implementation of Asset Health AssessmentSystem with Pattern-Oriented Design and Practice

Liqun Zhang, Avin Mathew, Sheng Zhang, Lin Ma

Abstract To integrate condition monitoring and relia-bility analysis with asset life-cycle management, a general-purpose asset health assessment system architecture is beingdeveloped. This system will assist management and main-tenance staff to make decisions based on condition and re-liability data, scientific analysis, and integrated informationthereby reducing the asset management cost for enterprises.

In this paper, a pattern-oriented software architecture de-sign is presented. The functionality of the system is exam-ined and some issues are identified. In particular, the paperelaborates on how design patterns are applied in the im-plementation of the different tiers in the system. It alsopresents a discussion detailing the system architecture thatfacilitates extensibility, flexibility, and robustness of the soft-ware system. To simplify the implementation of design pat-terns, various methodologies based on the in-built featuresof Microsoft .NET framework are applied.

Index Term-s Design Pattern, Asset Management, Deci-sion Support, Condition Monitoring.

I. INTRODUCTION

In modern industries, the maintenance cost of machineryconstitutes a significant proportion of industrial plant over-heads and is considered a target to improve profitability.Therefore, many industries are switching from time-basedmaintenance to condition-based maintenance to reduce ma-chine downtime and subsequently reduce costs. To conductcondition-based maintenance effectively, an asset health as-sessment system is required that will combine conditionmonitoring analysis, reliability analysis, and consider con-straints such as financial conditions to make predictionsabout the most economical period for maintenance [1] [2][3].The asset health assessment system involves information

from different sources, and the presented results vary fordifferent levels of users. Therefore the system involves so-phisticated data acquisition and processing, an intricateuser interface, as well as a substantial amount of commu-nication among modules. As a general-purpose system, thefunctionality should be able to evolve to accommodate dif-ferent industry demands. Therefore, the attributes of flex-ibility, extensibility, reusability, and openness are criticalfor the success of the system.

Design patterns are extremely powerful tools for soft-ware design as they use existing quality solutions to solverecurring problems [4]. These time-tested and field-testedsolutions will provide a better method to achieve the objec-

This research was conducted within the CRC for Integrated En-gineering Asset Management, established and supported under theAustralian Governments Cooperative Research Centres Programme.Authors are with the Cooperative Research Centre for Integrated

Engineering Asset Management, Queensland University of Technol-ogy, Australia

L. Zhang email: 14.zhang@Qqut.edu.au

tives aforementioned rather than starting completely fromscratch.To make the best use of design patterns, the asset health

assessment system is carefully examined and problems areidentified to ensure that these problems are addressed viawell-established solutions.The concept of design patterns has been well studied

in the academic literature. However, most examples usea separate illustration for each pattern [5] [6] [7] [8].This paper will describe the structure of the system, howdesign patterns are utilized, and how they cooperate andcommunicate with each other. The rationale of adoptingthese patterns will also be discussed. To simplify imple-mentation of the design patterns, various implementationmethodologies based on the in-built features of Microsoft.NET framework are described and compared.

II. DESIGN PATTERNS UTILIZED IN THE SYSTEM

In software design, a best practice principle is to ensurehigh cohesion within software entities and low coupling be-tween entities. This ensures the modification of one objectwill not result in modification of another object, therebyfacilitating software reusability and maintainability.

In object-oriented design, the open-close principle is oneof the core elements among the design principles. Theopen-close principle means software entities should be openfor extension, yet close for modification. That is, we shouldattempt to design modules that ideally never need to bechanged. To extend the behavior of the system, we addnew code without modifying the existing code. Confor-mance to this principle yields a great level of reusabilityand maintainability.

Recently design patterns have earned a reputation as atechnique for designing reusable, extensible, and easy tomaintain software. Cooperating design patterns providea better perspective on the design problems. It not onlymakes it easier to reuse the well-defined solutions to recur-ring problems, but also increases the system's robustnessagainst future changes.The design patterns adopted in the system are illustrated

in Fig. 1. They are organized and discussed according toa three-tier architecture of the system:. Data Layer is primarily responsible for interactions withthe database. The Factory Pattern and Adapter Patternwill provide a uniform means of database operation acrossmultiple database servers;. Business Layer implements design patterns such as Strat-egy Pattern, Visitor Pattern, Decorator Pattern, andFacade Pattern to achieve extensibility and flexibility ofsystem behavior; and

1-4244-0195-X/06/$20.00 ©2006 IEEE 666

Fig. 1. Design Patterns Adopted in the System

. Presentation Layer is responsible for user-interface-control and data presentation.The remainder of the paper will discuss the justification

and use of these design patterns and their interaction.

III. DEVELOPMENT OF PORTABLE DATA LAYER

In this asset health assessment system, a centraldatabase is designed to serve as a data repository and infor-mation exchange hub between system components. There-fore the data access layer, which responsible for interactionwith the database, is the most critical part of the applica-tion. Due to the general-purpose nature of the system andthe potentially diverse audience of users, a problem arises:how can the system be implemented such that it operateswith different database servers with a minimal number ofchanges?

This problem is addressed by using the Factory Patternand the Adapter Pattern to implement a portable dataaccess layer.

A. Database Transparency via Factory Pattern

To make the system work with multiple database servers,

such as SQL Server and Oracle, the Factory Pattern isapplied in the creation of the database objects.

Databas DatabaseFactoryDatabase = CreateDatabase(

fCreateDatabase(.A 4

L l---------- -------l F ---

return SQLDatabase return OracleDatabase X

Fig. 2. Factory Pattern in Database Creation

In the database's Factory Pattern, the abstract classDatabase is defined to provide the common interface fordata access operations and make code uniform across mul-tiple database servers. Two concrete database classesSQLDatabase and OracleDatabase are derived from thebase class, which contains concrete operations on SQL andOracle servers respectively.

Abstract creator class DatabaseFactory declares the

667

factory method CreateDatabase(), which returns anobject of type Database. Concrete creator classSQLDabaseFactory and OracleDatabaseFactory over-rides the factory method CreateDatabase() to return aninstance of a concrete database object.

All operations against database are conducted throughthe interface provided by the abstract classes Database andDatabaseFactory without knowing the specific database inuse, hence fulfilling database transparency.

In the Factory Pattern, a series of factory classes aredefined to create handlers of various databases. The Re-flection technique [9] in Microsoft NET can be utilizedto simplify the Factory Pattern implementation. Reflec-tion provides a way to create the concrete database classon-the-fly according to the configuration information, withDatabaseName stored and retrieved through a configurationfile [10].With the Factory creational pattern, details of creat-

ing specific databases are encapsulated, which assists inmaking the overall system independent from a particulardatabase platform.

B. Database Operation Abstraction via Adapter Pattern

A data layer represents a gateway to the underlyingdatabase. To make the application independent of thedatabase server used at the back-end, the details of in-teracting with a particular database should be hidden.Database command Adapter Pattern is adopted to fulfillthis purpose.

Fig. 3 illustrates the implementation of the databasecommand. DBCommandWrapper defines the common in-terfaces to support the database object, while leavingthe implementation to sub-classes SQLCommandWrapper andOracleCommandWrapper. These concrete command wrap-pers serve as adapters, adapting generic interfaces todatabase-specific commands, which encapsulate codes spe-cific to the particular database.

Client target DBCommandWrapper

+CommandTirmeut)AddPa raneters(

SQLCommandWrapper SQLCommandconmnard

",Parameters+ComrmandTimeout() +CommandTimeout(+AddParaeters() Parameters .Add()

cormmand.Parameters.Add(

Fig. 3. Database Access Adapter Pattern

The application deals with only base interfacesDBCommandWrapper, and can work with any concrete classthat supports this interface. As a result, the code becomesmore flexible and reusable.As an illustration, let us look at the code snippet for

data retrieval:

Database db =

DatabaseFactory.CreateDatabase(databaseName);DBCommandWrapper command =

db.GetSqlCommand(queryString);Command.addParameter(id);Dataset dt =

db.ExecuteDataSet(command);// .

We can see from the code snippet that through the Fac-tory Pattern and Adapter Pattern, abstraction from a spe-cific database is achieved and a uniform means of databaseoperation is implemented. With database-specific code be-ing isolated in interchangeable modules, the portability ofthe system data layer can be easily achieved.

IV. IMPLEMENTATION OF BUSINESS LAYER WITH

EXTENSIBILITY

Decision support within asset management involves in-formation processing related to technical, economical andsociological categories, among which technical issues covercondition assessment, reliability analysis and failure prob-ability and their impact on the system. In this paper, wetake condition assessment of engineering asset managementas an illustration.

A. Dynamic Algorithm Invoking with Strategy Pattern

In condition monitoring, a suite of algorithms is appliedin to gather overall information for assessments on the as-set condition. As the suite of algorithms is indeterminate,the system must allow for the future addition of analysisalgorithms.The data processing procedure is similar and the dif-

ference lies mostly in the algorithms adopted. To alterthe processing behavior without changing the fundamen-tal architecture, a strategy pattern is employed, which willencapsulate the algorithm and implement dynamic invoca-tion.The Strategy Pattern of system algorithms is depicted

in Fig. 4. A base class Algorithm is defined with commonfunction Calculation(0, and the individual algorithms,such as FFT, Cesptrum, Demodulation, are encapsulatedin sub-classes derived from Algorithm. Each subclass con-tains its own implementation for interface Calculation(0.

FF co itai Wm4For m

A1~1ys~ CGniroL AI r t5h

I I

Fig. 4. Strategy Pattern for System Algorithm

Usually no additional processing is needed when dis-playing waveforms. To process data in a uniform man-ner, a waveform algorithm class is defined, with itsCalculationo interface containing a NULL operation.

668

To achieve the dynamic algorithm invocation, a host ofcondition statements should be used to set the proper al-gorithm strategy at runtime.The NET Reflection technique is again employed to sim-

plify the dynamic invocation. Below is the pseudo-codesnippet for the implementation of analysis user control.

Class analysisCtrl {Strategy algoritm;// .

Public void SignalProcessing(string s){

Strategy s = getStrategybyName(s);SetAlgorithm (s);Calculation 0;

}

Public void Strategy getStrategybyName (string s){Assembly asm = Assembly.load(" AnalysCom.dll")Type type = asm.GetType(s);Strategy s = asm.CreateInstance(s);return s;

}

Public void SetFreqAlgorithm(Strategy s)

This.algoritm = s;I

Public void Calculate ()

This.algoritm.Calculate(0;

// ...

the Decorator Pattern, and feature trending is used as anillustration below.

Feature trending is arguably the most helpful means inobserving asset condition evolvement. In general, featureextraction is conducted upon uploading new data into thedatabase, and the time-based trending derived from accu-mulated feature data is displayed. In some situations rawdata are gathered directly from the database or other datasources. Features are extracted from the raw data, trended,and visualized. In other circumstances, the extracted fea-ture trends are stored in data files for information exchang-ing purposes.

Feature trending is implemented with Decorator Pat-tern, as shown in Fig. 5. The base class Featureis defined with the method DisplayFeatureTrending()as its basic service. In the derived decorator classFeatueDecoratorDB, the basic service is then augmentedby adding methods GetFeautreData()for acquiring fea-ture data from database, from spectrum data, or fromraw data files. While in the derived decorator class'FeatueDecoratorFiles, the functionality is extended fur-thermore by adding the method SaveTrend2Files() forstoring trend data into a trend file.

Feature

y,

*DsplaFatuikGersdinqtl

_IU

UreTrn"k' 0 L)

FeattireDrterata lS FeaturoDetoratorRes

;11DisiAaFO0yfeTirTenedin . DispdayFbeatu=eTlrw:1ndtgw}tinpyewr>rgl

ba7i 7y&[uo'~nig~~~~~S0 7t6hd2i1

}

In above code snippet, the function getStrategybyName ()supports dynamic creation of strategy objects using the.NET Reflection technique. The name of the algorithmto be invoked is passed into the function as a parameter.In the function, the Dynamic Link Library for algorithmsis loaded first. Based on the algorithm name, a concreteStrategy object is created and returned. The specific algo-rithm can then be conducted via this Strategy object. Inthis way, dynamic invoke of various algorithms is achievedby just passing the algorithm name.With the Strategy Pattern, algorithms can be modified

or added independently to the analysis control and/or anyother process logic, thereby greatly adding flexibility andextensibility to the business processing intelligent.

B. Pre-processirng and Post-processirng with Decorator Pat-tern

In condition monitoring, user requirements often vary, anda versatile approach to pre and post-processing is required.A novel approach is to meet these requirements by using

Fig. 5. Feature trending with Decorator Pattern

With the Decorator Pattern, the basic functionality canbe easily extended to meet different requirements.

C. Extend Functionality with Visitor Pattern

As the total functionality of each analysis control maynot be known a priori, the Visitor pattern is used to extendthe functionality without modifying the original objects.The Visitor design pattern is a way of separating meth-

ods from the object structure. It provides a separate in-terface which contains the method to process each type ofelement in the object hierarchy, and is implemented by allthe concrete visitors, as illustrated in Fig. 6.A simplified Visitor Pattern implementation under NET

is referred to in [11].With the Visitor Pattern, new functionality can be added

easily without modifying the core classes, providing flexi-bility and extensibility for system evolution.

669

Pes tSi Wsitor ReportVsi tor

+visitFFT(in F FTC3tri) *visltFFT0in FFTCtrl)*vislfflaveForm(fin VWaveFormC5trl *visifWveForm(in WtaveFormCtri)+visitTrend(in TrendC:tri) * isiflrend(in TrendCtrl)

bjectStruture-CtrULstElmn

L-fAdid(inl Elemienit) t+Ranovon Eiement) l*Acept(in Visitor)|1+Accepl(inVd i

foach Elrnente riL FFTCi WaveForCtr l TrendCtreAcceptivisitor) llll

1e4~~~~~~~+cca3pt(i i +A:ceptr}(l^pins tr| +Accept(in Visitor)

|visftor.visftFFT(thls) vlsftor.vlsitWaveForm(thi$

Fig. 6. The Visitor Pattern

D. Implement Higher Level Interface vi'a FaSade Pattern

In some circumstances, users may be interested in a

higher-level interface. For example, when assessing thehealth of a pump, the conditions of vibration, tempera-ture, pressure, and flow are important factors. However, aclient is usually not concerned about the underlying rea-

soning process, but instead about the overall health of thepump.

In this application, the Composite Pattern is employedfor the uniform interface of vibration diagnosis, whileFacoade Pattern is adopted for the coarse granularity serviceinterface.

In health assessment, vibration condition informationand diagnosis processes are encapsulated into asset faultdiagnosis classes, e.g. imbalance, misalignment and loose-ness. These classes provide a diagnosis on the conditiondata and deliver analysis results, indicating if the condi-tion is normal or if a fault is under development. TheComposite Pattern is employed to provide a uniform in-terface for vibration diagnosis, such that new diagnosticmethods can be easily added into the system with an un-

changed interface. The Composite Pattern for vibrationdiagnosis is displayed in Fig. 7.

IDiagnosis

Client foreach Du1tDisg j,h diagistqFConditionAssess( I* utaU1tU1.WUr1d1t!u^1nASeSSr+Add(in lDiagnosis)+R m ve DiosisI+Giet(n index inmt)r r ~~~~~~-diaglist I

VibDiagnosis

M sal gnemnt Looseness Imbalance +Coniionss(| ) l~~~+Add(in lD:iagnosis)|

+RemYove(in lDiagnosis)od iAes( +C o e r iiornA + nindex t

Fig. 7. Composite Pattern for Vibration Diagnosis

Technique parameters in operating process such as flowtemperature, pressure and current, should also be taken

into account when assessing asset condition. In addition,historical records have to be examined to indicate the assetcondition change.As users are often more interested in knowing the over-

all status of the asset (with perhaps very little interest inthe underlying reasoning process) the Facade Pattern, asshown in Fig. 8, is employed to meet this requirement.

Fig. 8. Facade Pattern for Health Assessment

The following code snippet shows how to use both pat-terns together:

class HealthAssessment {private VibrationDiagnosis vibDiagnos

= new VibrationDiagnosisO;private TechProcess techProcess

= new TechProcess ();private HistoryRecord hisRecord

= new HistoryRecordo;//p c l e

public bool IsHealthy 0){return (vibDiagnos.conditionAssess(0

techProcess.check()hisRecor.checko);

&&&&

}}

The HealthAssessment class encapsulates a sub-system foranalysing vibration condition, operation process, and his-tory record, and provides an overall health assessment in-terface to user. This not only enhances and simplifies thedesign of the application itself, but also is easily integratedinto a larger Service Oriented Architecture (SOA).

V. DEVELOPMENT OF USER INTERFACE

The graphical user interface (GUI) is a component inthe system that is most likely to change depending on userrequirements. Many smaller patterns are employed in theGUI development to accommodate future alteration. Asthese patterns have been described above, only a brief de-scription of the application of these patterns is given inregards to user interface development.

670

1.

A. Composite Pattern

The asset health assessment system frequently needsto manipulate the hierarchical collection of primitive andcomposite objects, for example, visualizing an asset mea-surement hierarchical tree. The measurement tree in asite contains a variety of segments; some segments mayhave only measurement channels, while others accommo-date multiple child-segments, etc. Displaying a measure-ment tree requires manipulating the graphic primitive el-ements or composite entities, and the layout calculationand display. The desirable methodology is to have uniformmanagement across all primitive and composite objects.The composite pattern can be adopted to achieve this pur-pose. It provides a common interface to components andcollections without distinguishing them, therefore reduc-ing the complexity of the application (refer to Section 4.4).When new components are added to the collection, theclient code does not need to be modified, making the ap-plication extensible.

B. Decorator Pattern

Most analysis user interfaces look similar, containingboth control panel and graphic display panels. But cer-tain interfaces for analysis types, such as Spectrum analy-sis, additional features such as the selection of window type,spectrum type and value type, are required. The DecoratorPattern is applied to add new requirements to the individ-ual Spectrum interface without affecting other interfaces.The Decorator Pattern can also be used to disable an inter-face element, for example, disabling the "select data file"button on the control panel. This is done by trapping anddiscarding input events, or by restricting access to sectionsof an object.

C. Strategy Pattern

The main interface of the application contains multipleanalysis forms, such as the wave form, FFT form, and de-modulation form. The common way of invoking differentforms under different circumstances is using a collection ofswitch statements, which will result in tightly coupled andhence difficult-to-change software.A better alternative is to use the Strategy Pattern. The

implementation is quite similar to the data processing al-gorithm aforementioned. We define an AnalysView class,which contains a common interface needed to display andupdate analysis forms, and encapsulate the different analy-sis forms into concrete implementation, such as WaveView,FFTView, DemodulationView. The application deals onlywith AnalysView interface rather than implementations.The specific analysis form to be displayed is dynamically in-voked with Reflection technique of Microsoft NET. In thisway, any analysis forms that implement the AnalysViewinterface can be added or changed without affecting themain form.

VI. CONCLUSION

In this paper, we have discussed the employment ofdesign patterns to implement a three-tiered asset healthassessment system. With the Factory Pattern and theAdapter Pattern, a portable data access layer is imple-mented which provides database independence through ab-straction. With the Strategy Pattern, Decorator Pattern,Visitor Pattern, Composite and Facade Pattern, the algo-rithms can be modified or added independently, the ba-sic services can be enhanced individually, and new opera-tions can be added on existing objects without modifyingthe original object structure. Using these patterns in thegraphical user interface will reduce the complexity of im-plementation and enhance the functionality as well.

Applying the design patterns to implement the assethealth assessment system is demonstrated as an efficientway to add flexibility and extensibility to the system, mak-ing it easy to convert the application to a Service OrientedArchitecture.The built-in features of Microsoft NET is demonstrated

to be a more efficient and effective way to implement somedesign patterns.

REFERENCES[1] A. Mathew, S. Zhang, L. Ma, T. Earle, D. Hargreaves Reduc-

ing maintenance cost through effective prediction analysis andprocess integration, Proceedings of the VETOMAC-3 & ACSIM-2004: 604-611, 2004.

[2] S. Pudney, L. Ma, J. Mathew, Y. Sun A high level asset manage-ment process model for the water utility industry, Proceeding ofVETOMAC-3 & ACSIM-2004: 767-774, 2004.

[3] Y. Sun, L. Ma, J. Mathew, S. Zhang Determination of preven-tive maintenance lead time using hybrid analysis, InternationalJournal of Plant Engineering and Management, 10(1): 2005.

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

[5] M. Nelson A design pattern for autonomous vehicle softwarecontrol architectures, Proceeding of COMPSAC '99: 172-177,1999.

[6] G. Naumovich Using the Observer Design Pattern for Implemen-tation of Data Flow Analyses, Proceedings of ASTE '02: pp61-68,November 18-19, Charleston, SC, USA, 2002.

[7] S. Yau, N. Dong Integration in component-based software devel-opment using design patterns, Proceeding of Computer Softwareand Applications Conference: 369-374, 2000.

[8] P. Astrom, S. Johansson, P. Nilsson Application of software de-sign patterns to DSP library design, Proceedings of ZSSS'OZ: 239- 243, October 1-3, Montreal, Quebec, 2001.

[9] J. Liberty Programing C# O'Reilly, 2003[10] D. Hayden Data access application block revealed - factory

methods and reflection, http: //codebetter. com/blogs/david.hayden/archive/2005/03/11/59644. aspx

[11] B. Wilson Using Reflection for the Visitor Pattern, http://www. dotnetdevs . com/articles/Ref lectionVisitor. aspx

671