Generic test environment for singIe-throw mechanical equipment by Saeed Fararooy and Nadeem Lehrasab

The design and development of a generic test environment for life-cycle testing and reliability analysis of single-throw mechanical equipment is outlined. STME is a generic class of ‘switching mechanisms’ or ‘reciprocating machinery’ widely used in industry. Everyday examples of STME are a car’s windscreen wiper and an automatic car-park barrier system. The case study considered here is that of a pneumatic train door. The benefits of such a robust environment in terms of flexibility and adaptability as well as an efficient method of data management and a platform for intelligent data analysis are demonstrated.

his article outlines the design and develop- ment of a generic test-environment for life- cycle testing and reliability analysis of single- T throw mechanical equipment (STME). The

case study considered here is that of a pneumatic train door; however, the research motivating this work also relates to the condition monitoring of other safety-critical railway equipment, namely train stops and point machines.

Single-throw mechanical equipment is defined in this article as a generic class of ‘switching mechanisms’ or ‘reciprocating machinery’ with a set of common characteristics that make them distinguishable from continuous dynamical systems. STME may be activated with pneumatic, hydraulic or electrical power and is often open-loop controlled. An STME has two stable states, and whenever activated, it physically moves from one state to another. Each transition is referred to as a single throw. The dynamics of each throw is a function of a number of static (steady-state) conditions and system parameters (states) based on the inherent characteristics of the equipment design. The transitional dynamics from state A to B and from state B to A may or may not be symmetrical.

There are many everyday examples of STME such as the windscreen wiper of a car or a car-park barrier

mechanism. Their operation is a repeated sequence of openiclose, leftiright or upidown movements. Since the two transitions are often not symmetrical, these are referred to as forward and reverse operations, respectively. STME are also widely used in industry as switching mechanisms. An example from the power industry is circuit-breakers where the switching opera- tion (ordoff) is achieved by mechanical action.

This article, first, expands on the motivation for the current study. A non-mathematical description of STME is provided and common characteristics are defined. The functional specification, hardware and software system design issues and implementation aspects of the test environment are outlined. The benefits of such a robust environment in terms of flexibility and adaptability as well as an efficient method of data management and a platform for intelligent data analysis is demonstrated using test results from a train rotary door operator case study. Finally, conclusions and future direction of research are presented.

Motivation The idea and concept of a generic test environment

for single-throw mechanical equipment arose from research activities funded by railway operators and manufacturers. These were concerned with remote

COMPUTING & CONTROL ENGINEERING JOURNAL JUNE 1998

&- I , test rig controller data analysis, presenlalion, storage

Fig. 1 S T M E test environment overview

condition monitoring of a number of STME case studies. The objectives of these studies were to detect incipient faults, improve equipment reliability and achieve a more cost-effective asset maintenance strategy. The research required a flexible and adaptable test environment and a development facility which could be exploited by manufacturers for life-cycle testing of their products and by operators during field trials and equipment approval process.

A number of equipment-specific test facilities, both hardware and software, were developed and used in the laboratory and during field Whilst the software elements of all such systems shared some common and readily reusable modules, it was clearly identified that much repetition occurred in software and particularly within the hardware. Each experience also revealed a number of limitations and deficiencies of the systems

Table 1 System requirements specif icat ion

STMF charact@stics ’ ’ Reqhirement. foi SAS ’. ’ Two stable states Incorporate state indicator and

decide next throw based on previous state

Forward and reverse throw Display and store forward and have . . diffsrent dynamics reverse throwdata separately Large number of samples Flexible dala-sets generation, at various pressures, management and export required to model facility an STME

Throw position varies non-linearly with time during throw period

Throw features can be a compact STME model

. . - .- .. _. ._ - Variable acquisition rate and number of samples supported to capillre the non-linear behaviour of throw profile

Throw features are extracted and stored for trend analysis

being developed, such as storage requirements of a large amount of field data for future offline analysis. In parallel to this, a number of off-the-shelf software packagesk7 for condition monitoring of continuous machinery or process plants were investigated. These were found to be either unsuitable or not easily applicable to STME. This led to the identification of a set of requirements and the functional specification of a generic test environment which would meet any of the following application areas:

laboratory test-rigs for evaluation of alternative intelli-

PC-based or embedded health monitoring for field

* life-cycle testing for product reliability assessment.

gent data analysis algorithms

trials

Single-throw mechanical equipment

from continuous dynamical systems are: The common characteristics that distinguish STME

(i) In general, an STME may be modelled as two dynamic systems with differing parameters for the two transitions (forwardreverse).

(ii) These two dynamics are activated within a recipro- cating discrete-event system. The final state of one dynamic determines the steady-state (static) para- meters of the other.

(iii) The distance travelled during both the forward reverse transitions is constant and the same.

For the pneumatic train-door operator, the main static parameters are the initial opedclose position and air pressure. The dynamics are represented in the displace- ment or velocity profiles.

COMPUTING & CONTROL ENGINEERING JOURNAL. JUNE 1998 &2%.

TESTING

Test environment functional specification

environment were identified as: The principles underlying the development of the test

maintainability-essential for a flexible develop-

reliability-f much higher degree than the system

efficiency-modular and generic approach for efficient

0 user-friendliness-for effective use of the test facility

mental system

being monitored

reusability

by various users and operators.

The major characteristics of the test environment may be summarised as follows:

complete isolation of forward and reverse throw infor-

trends visualisation and analysis of throw features and

throw dynamics monitor including filtering, re-

mation

other static measurements

sampling and feature acquisition

scheduler for life-cycle tests and carrying out a large number of tests with auto-run feature for daily operation dataset generation and management with export facility remote monitoring from any TCP/IF' address and Web

multiple users profile management static parameters with high order non-linear gain and throw features measurements online information about the hardware and software configurations robust state indicator for identifying correct state of the STME pressure ramping facility for lab operation to generate data for modelling purposes safety features such as pressure compressor turning off if pressure fails to build and audible messages before mechanical movements for STME in the case of unmanned remote operation.

Publishing

Fig. 1 presents an overview of the EP-STME test environ- ment and Table 1 summarises its features based on the specification of system requirements.

P--- PBWPABX

Internet real-time

remote control and monitoring machine generic test-rig server software package

laser printer for EP-STME

Fig. 2 STME test environment hardware

COMPUTING & CONTROL ENGINEERING JOURNAL JUNE 1998 143

Hardware design and implementation A generic hardware for the test environment allows

the user to operate an STMEmanually or through a computer and to capture information from multiple sensors in real time. The hardware (Fig. 2) includes a four- channel (analogue) STME control and data-acquisition unit. Each channel includes an independent STME control, signal conditioning and an interface to one additional external sensor. An optically-isolated control circuit switches a programmable power supply depend- ing on the requirements of the solenoid valves used for directing pneumatic pressure within an STME. Salient features of the hardware are:

a suitable and well-defined interface with data acquisi-

0 isolation for high-voltage solenoids 0 easy maintenance and troubleshooting 0 pneumatic pressure display a state indicators for an STME a interface for additional sensors

tion system

0 power supply for permanent sensors is made available; these sensors include airflow, angular displacement and air pressure sensor.

A generic power supply is one of the critical components of the hardware system. The excitation of various sensors may put stringent requirements on the power supply. A generic programmable power supply was therefore selected which can be easily converted or adjusted to requirements. At present, all required power supplies have been made available according to the specifications of available sensors and solenoid control voltages of existing STME in the laboratory. However, an external power source may be easily attached to the system.

The STME control circuit involves operating an STME for forward and reverse operations using appropriate solenoid valves. The voltage requirements of these valves vary from one equipment to another. The supply to the valves is switched using optically-isolated circuits. Manual operation of any STME is achieved using toggle switches.

Fig. 3 Object-oriented decomposition of the test environment software

COMPUTING & CONTROL ENGINEERING JOURNAL JUNE 1998 /

TESTING

WFWWw w:!: W R n T h m W ......... .................... 1 ........

........ .............. # j ( m; i

wla*D&se , , .

..._....._...I. .......................... .............. , .- None ... , ..

. . ..... .................... ! araCl*, ....... ,, ,'Y,'j i *+$;:,j w J

. . il..I .̂. .................. ........._.. ̂ : . ........... ~ ...................................... * . ~ . ._... Fig. 4 Test environment software user interface

The PC-based data acquisition unit comprises a data acquisition (DAQ) card, with eight-channel AiD converter and 24 digital I/O lines, used as input or output in groups of four or eight. There are also two D/A channels and three 16-bit independent countedtimers available.

The system configuration consists of multiple acquisi- tion cards installed in an industrial PC with state-of-the- art Windows N T server set-up. It acts as a Web server, as well as a data-acquisition server for STME test rigs. In addition, local data acquisition is carried out simul- taneously with multiple remote clients connected via either modems or TCP/IP links. Local report generation via laser printer is possible along with trend chart printing capabilities. A camera is used to monitor the STME physically at a remote machine for safety reasons. A multimedia system allows the audible voice messages to be played remotely for safe unmanned operation of the test environment. A digital air pressure indicator gives the current operating air pressure of the system as a safety feature. LEDs provide information about the state of an STME and the control mode.

Object-oriented software design and implementation

The most innovative aspect of the test environment relates to its object-oriented software. When designing a complex software system, it is essential to decompose it into smaller and manageable parts, each of which may

....... ~ i . . . " . ....... ~ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,

then be refined independently? This results in minimised coupling and increased cohesion? Object-oriented de- composition (Fig. 3) differs from algorithmic decompo- sition in that it decomposes the system into key abstractions in a requirement specifications domain. The conceptual framework for the object-oriented paradigm is the object model. There are four major elements of this model, namely:

Abstraction-denotes the essential characteristics of an object that distinguish it from all other kinds of objects and thus provides crisply defined conceptual boundaries, relative to the perspective of the viewer. Encapsulation-the process of compartmentalising the elements of an abstraction that constitutes its structure and behaviour; encapsulation serves to separate the contractual interface of an abstraction and its implementation. Modular&-property of the system that has been decomposed into a set of cohesive and loosely coupled modules. Hierarchy-a ranking or ordering of abstraction.

The benefits achieved from the object model are that it encourages reusability, leads to systems that are more resilient to change, reduces development risk and appeals to the working of human cognition.

The software, extending beyond 15000 lines of code,

COMPUTING & CONTROL ENGINEERING JOURNAL JUNE 1998 145

Fig. 5 Data acquisition server

message sent from client to

server

display onioff control

'. \

server port for .- connection

client connected signal

clear screen/ \ although it is

automatically cleared after

1000 messages

was implemented in C/C++ for a Windows 95/NT platform. Microsoft Visual C++ version 4.0 was used for implementing C++ code while ANSI C code was written mostly using LabWindows/CVI libraries from National Instruments. The interface (Fig. 4) is completely con- figurable by the user. A high level of data validation and error control allows robust and reliable data acquisition and storage.

The primary components of the test environment software package, each of which exhibit well-defined

interfacemanager data acquisition and control manager remote access manager database manager export filters data-sets manager schedule manager.

Profile manager has two major components, namely profile data and profile configuration. Multiple profiles

behaviour, are:

profile manager

Fig. 6 Remote data acquisition set-up

may be created each containing information required to operate and acquire data from an STME. Profiles can be optionally protected by a password. Copying data from

rem monitoring PBX;PABX 1

i modem a -,

.... . .- .

/' I @U

reniole test-rig test-rig server monitoring

Internet web browser

COMPUTING & CONTROL ENGINEERING JOURNAL JUNE 1998

existing profiles to create new ones saves time and is efficient. A user may configure a profile containing the following key information:

0 up to eight digital-sequences required for controlling

0 eight static and dynamic channels 16 throw features, e.g. for monitoring throw times

0 storage information about data to be logged 0 user interface customisation

sound files for remote operation of an STME 0 remote operation set-up.

STME

Interface manager is a collection of complex components which allow the user to view and log data acquired during forward and reverse throw of an STME. It

includes:

trend analyser to view, print and export trends throw dynamics analyser to view the dynamic signa- tures of data from various sensors during the STME transition static parameters displayed before and after the throw features data displays state indicator throw control switch information board pressure ramp controller forward and reverse throw counters.

The interface manager uses the data acquisition and control PAC) manager to acquire data and direct it back

Fig. 7 Data set manager

Fig. 8 Trends analyser with export filters

COMPUTING & CONTROL ENGINEERING JOURNAL JUNE 1998

TING

to the requesting component. The DAC manager has two separating modes: local control and external trigger (involving continuous monitoring of the trigger event).

Remote access manager allows remote operation by sending data acquisition commands to remote machine to retrieve information. Any remote machine with a valid TCP address running Data AcQuisition (DAQ) Server (Fig. 5) can receive commands and direct acquired data back to the client. The DAQ server is a stand-alone program which converts any PC with a valid TCP address to a server.

Another way to access the test environment server remotely (Fig. 6) is through any Internet browser. If a valid password is entered, remote control over the Internet is allowed. A real-time camera image is also available on the Internet.

Database manager allows the user to individually select any dynamic or static parameter or throw feature for logging. Data sets for forward and reverse throws are automatically stored separately and the user can export data sets to any valid local or network directory path.

Data-set manager (Fig. 7) keeps track of the number of throws carried out. Static parameters and feature data of all throws are stored in individual files, while there is a separate file for dynamic data for each throw. The user can view and print the information to see the summary of data being logged. Static parameter filenames can be configured in the profile manager. Dynamic data filenames have the throw count as the post-fix.

Expovt filters (Fig. 8) allow the data to be exported to third-party packages for mathematical analysis and data visualisation. They also allow deletion of files while exporting to avoid storage of multiple copies of same

data. The special feature is to export trends of data, e.g. pressure versus throw.

Scheduh munager can perform a specified number of operations after preset time intervals. The three primary modes of operation are:

(a) Immediate: Performs a specified number of opera-

(b) Daily: Performs a specified number of operations

(c) Long term: Performs continuous daily operation over

tions immediately.

daily within a specified time interval.

a long period, typically for life-cycle testing.

The schedule manager can be launched in auto-run mode. In this case, whenever the test environment is powered up, it automatically starts executing the last schedule. The scheduler is automatically disabled if the STME stops toggling its state on application of control signals. Safety features are integrated into the system to avoid any damages during unmanned operation. Data sets are automatically generated daily, weekly or on a monthly basis. This can prove to be a useful tool for carrying out millions of operations with absolute safety.

Results and data visualisation The system was thoroughly tested for reliable data

acquisition. A large number of operations were carried out to test the acquisition, storage and export facilities. Portability of data to third-party packages has also been tested. The Windows NT-server is currently publishing information onto the Internet. Remote monitoring, with multiple STME operating concurrently, has been practi- cally tested. Data acquired from the test environment

Fig. 9 Data acquired from the train door operator test-rig using the generic test environment: ( U ) Train door closing; (b) Train door opening

COMPUTING & CONTROL ENGINEERING JOURNAL JUNE 1998

Fig. 10 Embedded FDI system

(Fig, 9) has been exported into Matlab and compared with the output of a standard oscilloscope to confirm the acquisition reliability. The results are shown in 3D- graphs showing pressure (35-75 psi), angular displacement (&lOO%) and time in seconds for train rotary door operator.

Results can be processed and visualised using the toolbox developed in Matlab. This toolbox allows the analysis and mathematical modelling of data using various techniques and implements novel fault detection and isolation (FDI) algorithms for an STME. The model of STME, optimised for speed and memory space, is inserted as a header file in the embedded system software.

Embedded FDI system Embedded FDI system is another interesting develop-

ment. This allows the development and robust testing of algorithms written in pure ANSI C, highly portable to other platforms. Results are processed and passed back serially to the main computer for performance analysis and optimisation based on practical results (Fig. 10). Comparison with Matlab simulation is a good measure of the embedded system performance. Thus, to produce a low-cost solution, the environment may be used for designing and testing algorithms for embedded FDI systems.

Conclusions A novel generic test environment for a class of single-

throw mechanical equipment is presented and its application for life-cycle testing and reliability analysis discussed. Based on a formal definition of STME and their common characteristics, requirements and functional specification of the test environment are outlined. The hardware and software system design

features and implementation aspects are summarised. The benefits of such a robust environment in terms of flexibility and adaptability as well as an efficient means of data management and a platform for intelligent data analysis are clearly elaborated.

References 1 FARAROOY, S., and ALLAN, J.: ‘Field trials of condition monitoring

system for railway signalling equipment’, IRSE ASPECT ’95, London, 25th-27th September 1995,324-334

2 LEHRASAB, N., and FARAROOY, S.: ‘Using Lab Windows/CVI for train door health monitoring system’, Best Virtual Instrumentation Application Award, NI-Day Europe ’96, 12th-13th November 1996, Newbury, UK

3 ABED, S. K., FARAROOY, S., and ALLAN, J.: ‘PC-based condition monitoring system to verify reliability-centred maintenance of electro- pneumatic point machines on London Underground’, IEE Int. Conf. on Development in Mass-Transit Systems, April 1988

4 CHRISTINE, L., TSIEN, S. M., and JAMES, C. F.: ‘An annotated data collection system to support intelligent data analysis of intensive care unit data’, in ‘Advances in intelligent data analysis’, LIU, X., COHEN, P., and BERTHOLD, M. (Eds.) (Springer-Verlag Berlin Heidel- berg, 1997)

5 LAPE A., and KRANZ, G.: “euro-fuzzy diagnosis system with a rated diagnosis reliability and visual data analysis’, in ‘Advances in intelligent data analysis’, LIU, X., COHEN, P., and BERTHOLD, M. (Eds.) (Springer-Verlag, 1997)

6 Data Engine (Software), 199&97, MIT-Management Intelligent Tech- nologien GmbH, Germany

7 SCHIEFFER, B., and HOTZ, G.: ‘Diagnosis of tank ballast systems’, in LILI, X., COHEN, P., and BERTHOLD, M. (Eds.) (Springer-Verlag Berlin Heidelberg, 1997)

8 PRESSMAN, R. S.: ‘Software engineering: a practitioner’s approach’ (McGraw-Hill, 1992,3rd Edn.)

9 SOMERVILLE, I.: ‘Software engineering’ (Addison-Wesley Publishing Co. Inc., 1995,5th Edn.) 0 LEE 1998

T h e authors are with the School of Electronic and Electrical Engineering, The University of Birmingham, Edgbaston, Birmingham B15 2TT, UK. Nadeem Lehrasab would like to acknowledge the Government of Pakistan for sponsoring his PhD H Dassanayake, C C Chu and A Dunn are gratefully acknowledged for their contribution to this project. The Web- server address is ht@://eee86.bham.ac.uk (trial service awaiting official IP address).

COMPUTING & CONTROL ENGINEERING JOURNAL JUNE 1998