Microcomputer-based remote terminal unit for a SCADA system

ELSEVIER

MI(SROPROCESSORS AND

MICROSYSTEMS

Microprocessors and Microsystems 20 (1996) 39-45

Technica l app l i ca t ion

Microcomputer-based remote terminal unit for a SCADA system

G.T. H e n g

School of Electrical and Electronic Engineering, Nanyang Technological University, Nanyang Avenue, Singapore 2263

Received 15 January 1995; revised 17 October 1995; accepted 19 October 1995

Abstract

This paper describes the design of a low cost and versatile microcomputer-based remote terminal unit that was commissioned as part of a SCADA system for an oil and gas company in the Middle East. The remote terminal unit talks to the master or host computer using a leased telephone line. The changes in field inputs are reported by the remote unit to the host computer in real time while control outputs can be sent by the host computer to the field immediately. One unique feature of this remote unit is that it performs gas flow calculations and serves as a backup to a sophisticated flow computer installed at the remote site.

Keywords: Remote terminal unit; Structured array database; Message protocol; Report-by-exception; Select-before-operate; Flow computation; Preventive maintenance terminal

1. Introduction

As defined by ANSI, the term remote terminal unit (RTU) "refers to a remote station equipment of a supervisory system" and the term supervisory system encom- passes "all control, indicating, and associated telemetry equipment at the master station, and all the complemen- tary devices at the remote station, or stations" [1]. A working definition of a supervisory system was adopted in the 1994 IEEE tutorial course on Fundamentals of Supervisory Systems, as a collection of equipment that will provide an operator at a remote location with enough information to determine the status of a particular piece of equipment or an entire substation or power plant, and cause actions to take place regarding that equipment or facility without being physically present [2].

Since the RTU interfaces with the real-world devices, it is usually considered the eyes, ears, and hands of the master station. The inclusion of a microprocessor in the RTU has made it possible to off-load the communication channel as well as the master station computer by per- forming some of the further processing steps previously done by the master computer. In this way overall product cost is reduced, flexibility is improved and performance enhanced.

With the tremendous falling cost and rising capability of microcomputers, the RTUs, the master station

0141-9331/96/$15.00 © 1996 Elsevier Science B.V. All rights reserved SSDI 0141-9331(95)01066-1

man-machine interfaces (MMIs) and even the host computer may be microcomputer-based. By incorporating the microcomputer into the system design right from the beginning, the design can be kept simple with minimum additional hardware. Further the ability to be pro- grammed in high-level language is an advantage. High- level programming is much less primitive and tedious compared to assembly programming, decreasing errors and enhancing understandability, but has produced less efficient machine instructions, leading to higher memory requirements and lower overall performance. However the general performance level of the current microcomputers with high-level programming is high enough, above that required for most RTU functions, that the remaining inefficiencies are not important. There will also be great advantages in terms of maintainability (ease of maintenance), versatility (ease of configuration) and adaptability (or interchangeability).

This paper describes the design of a microcomputer- based RTU, both in terms of hardware and software design. There are also brief descriptions of the message protocol used to accomplish message integrity as well as minimum response time between the RTU and the host computer. The principles used in the gas flow computations and the maintenance philosophy of the RTU are also discussed. This paper concludes with a very brief description of the host computer (in order to give a complete picture of the supervisory control and data

40 G.T. Heng/Microprocessors and Microsystems 20 (1996) 39-45

acquisition system) and highlights the various applications for such an RTU. The complete supervisory control and data acquisition (SCADA) system was successfully commissioned for an oil and gas company in the Middle East and is used to measure the amount of gas supplied to its customer so that the customer can be billed accordingly.

Flow Computer Link

2. Hardware design

2.1. R TU configuration

In the SCADA system which was commissioned, the RTU sits in a Control Panel which is located at the Gas Pipeline Receipt Station about 100 km from the Master Station. The Control Panel is actually a 19 inch rack consisting of a digital clock, an alarm anunciator panel, a dedicated flow computer, the RTU, the emergency shut-down (ESD) valve manual control panel as well as the various field terminations.

The housing of the RTU is basically an industrial PC chassis, with a 12 slot backplane, and is equipped with a power supply, a cooling fan and a 3.5 inch disk drive. The basic configuration of the RTU comprises of a plug- in processor (CPU) card, a plug-in ROM/RAM card (which emulates the disk functions so that the software may reside either in EPROM or SRAM), a plug-in modem card and a display card. The display monitor and the keyboard are not part of the basic configuration but they will be used when there is a need for change of software or during troubleshooting.

In this RTU, there are also 3 digital input/output cards, 2 analog input cards and 1 analog output card to handle the 30 digital input points (for the various field status), 8 digital outputs (for the ESD valve and alarms), 4 analog inputs (for the high and low range differential Pressure, static pressure and temperature transmitters) and 1 analog output (for the gas flow indicator) respectively. With the above configuration, several RTUs may share a common pool of plug-in cards so that there is a great degree of interchangeabiilty and thus reduces spares requirement.

An 8-port serial card handles the communications between the RTU with the host computer, the PMT and the flow computer. The serial port, COM 1, is used for communications with the host computer via the plug- in 1200 baud CCITT V23 modem card and 4-wire leased telephone line. Serial port, COM2, is used for communications with the PMT, so that maintenance personnel at the site will be able to interrogate the RTU without going through the host computer. This PMT concept is ideal for on-line calibration and troubleshooting. COM3 is used by the RTU to interrogate the flow computer to obtain the computed gas flow values so that these values can be sent back to the host computer.

Local Console

Microcomputel Bus

M ,er S, ,ioni:iI Communications Interface

put I p'u'e I

Analog Transmitters Contact Inputs Analog Indicators Contact Outputs

Fig. 1. RTU functional block diagram.

An RTU functional block diagram is shown in Fig. 1.

2.2. Input~output

The analog input cards offer 12 bits resolution and this works out to a quantising error of + or -0.012% of full range. There are 2 trim potentiometers provided on each card for zero and span adjustments during calibration. There is also an LED which will light up every time the analog input card is read, which is useful as a diagnostic tool. The 4 to 20 mA analog inputs from the field transmitters are sent to these cards through surge withstand terminations, which will protect the RTu from the external noisy and often hazardous environmental conditions.

The digital input/output cards can handle both wet or dry contact inputs and are also provided with contact debouncing circuits. The field signals are terminated on an opto-isolated and relay panel before being sent to the cards in the RTU. Each field status is indicated by an LED on the card, which serves as a good troubleshooting tool.

The analog output card also offers 12 bit resolution with a dedicated digital to analog converter for each channel. Thus there are 2 trim potentiometers for zero and span adjustments for each channel, for calibration purposes. In this RTU, the analog output card is used to supply a 4 to 20 mA signal that is proportional to the RTU computed gas flow value and this current signal is used to drive a gas flow indicator for the customer.

2.3. Flow computer

G.T. Heng/Microprocessors and Microsystems 20 (1996) 39 45

The analog input signals from the field transmitters are sent to both the RTU and the flow computer in series so that both systems will have identical current inputs to perform flow computations. (During commissioning, the 2 systems are calibrated independently using a single current source.) The total gas flow values computed by the flow computer will be sent to COM3 of the RTU, so that the RTU will send these values, together with the RTU-computed total gas flow values, to the host computer. Under normal circumstances, the host computer will generate reports based on the flow computer computed gas flow values. In the event of a flow computer failure, the RTU will activate an alarm so that the host computer will then use the RTU-computed values instead. A manual switch is also provided in the Control Panel which allows the operator to isolate the flow computer and thus choose to use the RTU-computed values, for whatever reasons. The flow computer also provides an analog output that is proportional to the computed gas flow value and this is also sent to the customer's gas flow indicator.

2.4. Emergency shut-down (ESD) valve

In case of emergency or accidents, the ESD valve should be shut so that the gas supply is stopped. This valve can be activated manually from the Control Panel or from the main gate of the Gas Pipeline Receipt Station. The valve can also be activated from the host computer, where a command is sent from the host computer to the RTU using the select-before-operate (SBO) sequence. This SBO sequence is described in a sub- section below.

3. Software design

3.1. Operating system

In this particular system that is commissioned, DOS is used as the operating system (OS) as it is able to meet the required specifications. Further as long as the individual tasks are run sequentially and there are proper memory handling procedures, there is no danger of task memory over-writing. In any case, this section highlights the algorithms for the various modules and methodology of an RTU software and these can be ported to other platforms or environment with a different OS.

3.2. Software modules

The software is partitioned into logically complete modules, so that they can be tested and maintained independently. The designer can then tailor the RTU to

41

different environment or functionality by changing only the affected modules.

There are a total of 7 basic tasks (each task is made up of several functional modules) carried out by the software. The clock task (CLKTSK) maintains a real-time clock that is synchronised by the host computer during start-up as well as at every midnight. The scan task (SCNTSK) reads the field signals including the flow computer and updates the database accordingly. While the digital inputs are read very frequently, the analog inputs are scanned once every second and the flow computer once every 10 seconds. These scan rates may vary, depending on requirements. The handshaking between the processor and these inputs will not only ensure data integrity but the processor will also be aware of the health status of the individual modules. The report- by-exception task (RBETSK) checks for RBE condition and activates a flag if the condition is satisfied. This task or feature is described in detail in the next section. The communication task (COMTSK) handles all the communications with the host computer. The message task (MSGTSK) processes all incoming messages, prepares the reply messages and sends out control outputs when- ever requested. This task has different subroutines to handle messages with different function codes (the various messages with different function codes are described in the 'message protocol' sub-section). The PMT task (PMTTSK) services all the data request from the PMT. Details on the PMT are provided under the section on 'maintenance'. The watchdog task (WDGTSK) ensures that each task does not exceed the time limit allocated.

The COMTSK and PMTTSK, which handle the communications with the host computer and the PMT, are both interrupt driven so that they are only executed when there is data in the receiver or transmitter queues (this eliminates idle waiting time). It should be noted that the COMTSK and the PMTTSK do not share the same queues since the data comes from different COM ports. There is no need for communications with the flow computer to be interrupt driven since the data is read by the RTU at regular intervals.

Communications among the various tasks is implemented through a set of common memory areas. For example, the host computer receive and transmit message buffers are shared between COMTSK and MSGTSK while the RTU database is accessible to all the tasks except COMTSK and WDGTSK.

3.3. Configuration files

There are a total of 5 adaptive configuration files, which essentially contain the complete configuration of the RTU. Upon initialisation, the software will read from each of these files as the start-up conditions. The system configuration file (SYSTEM.DAT) defines the configuration which is unique for each RTU within the

42 G.T. Heng/Microprocessors and Microsystems 20 (1996) 39-45

system. The analog input file (ANAINP.DAT), the digital input file (DIGINP.DAT) and the accumulator input file (ACCINP.DAT) define the parameters required for the input modules. The flow computer data file (FLOWCM.DAT) defines all the parameters required to perform flow computations.

The main advantage of having these adaptive configuration files is that the same system software can be used for different RTUs and only the configuration files need to be changed (and this can be done by the user) for a different configuration or simply for different addresses and number of input/output channels. These configuration files also allow the RTUs to start acquiring data based on initialised conditions even when the communications with the host computer is not yet established. Once the current configuration is successfully downloaded from the host computer to the RTU, these files will be updated so that they will always contain the latest configuration of the system.

3.4. Database

The database contains the latest configuration and field status of each input/output channel and is accessible to the CLKTSK, SCNTSK, RBETSK, MSGTSK and PMTTSK. It contains system level data like the real-time clock (year, month, day and hour, minute, second) as well as data for each input/output channel. The data for each channel is kept in a structure while the structures for all the channels of the same data type (e.g. analog input) will be kept in an array. This structured array database allows quick and easy access to the data from the various tasks.

The analog input, accumulator input and the digital input databases not only contain the basic configuration data (as found in the configuration files), but also contain the current raw and processed readings. The digital input database also contains some flags used to implement a digital filter. This digital filter will only recognise a gen- uine status change when there are 5 non-status-changes following a status-change. It will ensure that the data is stable immediately after a status-change, before it is being reported. Thus this debouncing logic will eliminate any contact-bounce, glitch or spike which may affect the status input and prevent it from being reported to the host computer. The analog output and digital output database contains the set and execute data to ensure that all control outputs are carried out in a 2 stage pro- cess of select-before-operate, for safety and integrity.

4. Communications

The communication scheme used in this project is similar to that defined in the IEEE recommended practice and is based on the principle that remote terminal

messages are transmitted only in response to master terminal messages that explicitly request such responses [3]. Further byte-oriented protocols are used to reduce communication system loading and take full advantage of microprocessor capabilities.

4.1. Message protocol

The message format consists of 3 basic fields viz. 'message establishment', 'information' and 'message termina- tion'. The 'message establishment' field provides the signals to synchronise the receiver and transmitter, and basically consists of the sync subfield and the remote address subfield. For the sync subfield there are optimum sync patterns which require the largest number of received bit errors to cause sync slip and these are defined in the IEEE recommended practice [3]. The remote address of each RTU is unique (in the range of 1 to 254) while remote address 255 is used only for broadcast messages (applicable to all RTUs). The 'message termi- nation' field provides the message security check and a means of denoting the end of the message. In our case, we are using the 16 degree polynomial cyclic redundancy computation (CRC16), which most agree is the most reliable security checks [2]. The 'information' field, which usually forms the main bulk of the message, provides the data in a coded form to allow the receiver to decode the information and properly utilise it.

Upon initialisation, the host computer will send a set- date-and-time message to the RTUs for time synchroni- sation. This message will also be broadcast to the RTUs at every midnight, to overcome the slight deviation in system clocks. When the message is received correctly, the RTU will reply with a set-date-and-time acknowledge message. At this point, the host computer will attempt to download the database (i.e. the configuration like the conversion slope and intercept, RBE window, RBE mask status etc.) to the RTU using'the block put message and the RTU is required to acknowledge receipt. Once the database is downloaded, the host computer will request for a complete database update from the RTU. The poll message is used regularly by the host computer to poll the RTU and the RTU may reply with an RTU restart message (if the RTU has just restarted) or it may reply with an RBE message or a no-reply message, depending on whether there are any outstand- ing RBE messages in the RBE circular buffer. A poll previous message is used by the host computer when there is no reply received from the RTU. Thus for each message to be transmitted by the RTU, it is necessary to retain the message in a transmit buffer, so that in case the message is not received correctly, the message from the transmit buffer can be re-transmitted again. The random get message allows the host computer to request for an update of the latest field status from the RTU without having to wait for an RBE. The random put message

G.T. Heng/Microprocessors and Microsystems 20 (1996) 39-45

allows the host computer to change specific values in the RTU database.

Each of the above type of messages is denoted by a unique function code and the most significant bit of the host computer message function code is zero while that for the RTU message function code is one. This provides further distinction between messages originating from the host computer and those from the RTU.

43

retransmits it ('check') to the master terminal for verifi- cation. If the data contained in the first remote terminal message is found to be identical to that previously transmitted, the second master terminal message ('execute') instructs the remote terminal to make use of the data previously stored. Valid receipt of the Execute message initiates the second remote terminal message ('Execute Acknowledge') confirming data acceptance [3,4].

4.2. Report-by-exception (RBE)

The command and control centre requires updates of the field status to be reflected in the event log as well as graphically on the terminals of the host computer. This can be achieved by making the RTUs report all status when polled by the host computer. However depending on the speed of the polling and the size and number of RTUs, the communication channels may be jammed up and the update may not be real-time. In order to avoid these problems and to achieve real-time (if not near real- time) updates, the RBE concept is introduced. In this concept, the RTU will only report (or update) the change since previous reporting, in the case of analog inputs or accumulator inputs, when it exceeds the specified RBE window (expressed as a percentage of the current value). For digital inputs, RBE condition is only satisfied when there are 5 non-status-changes following a status-change, implemented by the software digital filter. For analog and accumulator inputs, there is also a forced RBE rate which enables the host computer to 'force' the RTU to perform an RBE reporting at regular time intervals. This feature is especially useful for very slow changing inputs.

The RBE messages are time-tagged with the exact date and time (from the real time clock maintained by CLKTSK) at which the RBE condition was detected, and these are kept in an RBE circular buffer. A circular buffer is used here so that in case of communications failure (when the RTU is unable to report to the host computer) and unreported RBEs fill up the buffer, an RBE buffer overflow flag will be activated and the oldest RBE message in the buffer will be replaced by the latest RBE message.

In case a particular channel is faulty, the RBE function of that channel can be masked until such time when the channel is restored. In the meantime, the communication channel is not jammed up and the RBE functions for the other healthy channels are not affected.

4.3. Select-before-operate ( SBO)

The select-before-operate feature is identified as the 'select, check, execute' transaction in the IEEE recommended practice. The first master terminal message ('select') transfers the data to the addressed remote terminal, which temporarily stores the received data and

5. Flow computations

Constants like the orifice and pipe diameter, type of pressure tapping for the orifice plate, ratio of specific heats, dynamic viscosity, etc., are keyed into the flow computer during commissioning, which are also read by the RTU upon start-up. Thus based on this same set of constants as well as inputs from the analog transmitters, both the RTU and the flow computer calculate the rate and amount of gas sent to the client's customers. Under normal circumstances, both sets of computed values are reported to the host computer from the RTU but only the flow computer computed values are used for report generation. In the event of flow computer failure, there will be an automatic switchover so that the RTU computed values will be used instead. As the customers are billed according to the reports generated, the accuracy of these flow computations is essential.

According to the International Standard ISO 5167-1 [5], the mass flow rate, qm (in kg/s), is calculated from:

C 7rd2 ~ qm ---- l ~ - - - - ~ ~4 el ~

where C = coefficient of discharge,/3 = diD ratio of orifice diameter to pipe diameter, el = expansibility factor, d = diameter of orifice in m, Ap = differential pressure in Pa or N/m 2, Pl = flowing density of fluid in kg/m 3. The expansibility factor is given by:

e~ = 1 - (0.41 + 0.35/34) Ap ~Pl

where/3 = d/D ratio of orifice diameter to pipe diameter, Ap = differential pressure in Pa or N/m z, ~; = isentropic exponent or ratio of specific heats, Pl = absolute static pressure of the fluid in Pa or N/.m 2. Using the Stolz equation, the coefficient of discharge can be calculated using:

C = 0.5959 + 0.0312/321 - 0.184/38

( 1 0 6 ~ 075 + 0.0029/32.5 \ ReD] +0.09L1~34(1 _ /34)-1

- 0.0337L~/33

where/3 = d/D ratio of orifice diameter to pipe diameter, ReD = Reynolds number referred to the pipe diameter,

44

L1 = quotient of the distance of the upstream tapping from the upstream face of the plate and the pipe diameter, L~ = quotient of the distance of the downstream tapping from the downstream face of the plate and the pipe diameter.

From the above equation, it can be seen that the coefficient of discharge is related to the Reynolds number but the Reynolds number is again related to the mass flow rate as shown below:

4qm ReD --

zr#l D

where ReD = Reynolds number referred to the pipe diameter, qm = mass flow rate in kg/s, D = internal pipe diameter in m, #l = dynamic viscosity of fluid in Pa.s.

Thus the mass flow rate can be calculated from the measured differential and static pressures and temperature using the above equations, only after a few itera- tions. The total flow can be easily calculated from the flow rate by multiplying it by time.

The accumulator input database is used to store the flow computer computed rate and total gas flow as well as the RTU-computed rate and total gas flow. One obvious advantage is that the 'RBE windows' and 'forced RBE rates' features can be used accordingly, for the RTU to report these gas flow values to the host computer. Further, the RTU-computed total gas flow is indeed like any accumulator input parameter, which may rollover and can easily be reset from the host computer.

6. Maintenance

The maintainability of the RTU is given considerable attention as it has major effects on the total life cycle cost [6]. In this case, the RTU is designed to be modular and simple so that not only the repair times will be lowered but also the initial and recurring training costs for maintenance personnel. In fact since the RTU is essentially a microcomputer, most computer-literate maintenance personnel will require very little training. There are no special test equipment required and the only maintenance tool is a PC (or lap-top for mobility) running a standard communications software. Further with all the RTUs sharing a common pool of cards, the spares requirement is minimised.

6.1. Diagnostic

It makes a big difference if the maintenance technician finds it easy to interact with the RTU and is able to get the faulty RTU back on line in the shortest time. Thus the cards in the RTU have a liberal number of indicating devices (or LEDs) which give the technician immediate clues as to what is working correctly and what is not.

There are also built-in software diagnostics which are


run upon power up, and there is periodic handshaking between the processor and the input/output cards to monitor continuously the hardware performance of the RTU. Each line-replaceable-unit (LRU) in the RTU will have a designated pseudo-status point to indicate its health status and these points are reported to the host computer like any other digital input status points.

The watchdog task, as described in the software module sub-section, ensures the proper operation of the software. It allocates a certain amount of time for each task and will 'kick' or re-start the RTU if this time lapses due to hardware or software failure.

6.2. Preventive maintenance terminal ( P M T )

The PMT is essentially a PC that emulates a dump terminal and is used for the calibration of the input/output cards as well as for maintenance and troubleshooting. The PMTTSK in the RTU services the communication with the PMT to allow it to interrogate the RTU on-line. In our case, the PMT is a laptop computer that is carried by the maintenance personnel to the remote site and it runs the Procomm software to emulate the VT-52 terminal. Depending on the keystrokes hit from the laptop, the PMTTSK in the RTU will send the relevant data to be displayed on the screen of the laptop. The PMT can display the latest field status of the analog inputs, digital inputs, accumulator inputs (in this case gas flow values), analog outputs and digital outputs in separate pages. These data will be especially useful during calibration and maintenance. The PMT can also display the communications transactions between the host computer with the RTU and these transactions can be logged for future reference or for troubleshooting purposes. The PMT also allows the maintenance personnel to change the configuration of the RTU without having to do it from the host computer. However this feature is password protected so as to prevent unauthorised change of the database. This feature is used most extensively during the calibration and testing of the analog and digital outputs.

The capabilities of a PMT can make a big difference in getting a faulty RTU back on line as the maintenance personnel will find it-easy to interact with the RTU. In fact it can save the user many recurring dollars in minimising maintenance downtime. Further with the PMT, there is no' need for the installation and maintenance of instru- ments, panels, control switches and associated wiring at the remote station. In such harsh remote environment, it is definitely advantageous to have the PMT in the form of a laptop that can be carried away when not in use.

7. Host computer

In this particular project, the host computer at the


Control Centre is also a PC with an identical plug-in modem card to handle the communications via the leased telephone lines. Several tasks run on this PC which also handle the on-line graphical display, the secured log-in, the different priority alarm activation/acknowledgement and log, the generation of reports and database, the on- line trending and the change in RTU configuration. The user may use the tools provided to create his own graphical displays for representing the field configuration. This may be in the form of schematics, single-line diagrams, etc. and can be dynamically linked to the actual field values and status. Depending on the security level of the user, the user may also activate control outputs simply by clicking on the graphical displays. For the gas flow computations, four different types of reports are generated every 2 hours, every shift of 8 hours, every day and every month. These reports show the total gas flow (supplied to the customer) amongst other data.

8. Application

Other systems with similar configurations have also been commissioned for the water and building industries. In the water industry, the level and flow of water at reservoirs and water treatment plants are monitored and reported to the master station while in the building industry, usually lifts' status are monitored.

It can be seen that the PC-based configuration may be used for RTUs, for host computers, for sub-master computers, for communication controllers as well as for man-machine-interfaces. In fact as we move towards distributed systems, decentralised I/O processing, inte- grated sub-station protection and control, this PC- based configuration can be used at every level. The trend is basically to move more and more of the intelli- gence away from the master station to the lower levels, to reduce the loading on the master station as well as the communication system.

9. Conclusion

45

The design of a microcomputer-based RTU for SCADA systems has been presented. This RTU was successfully implemented and commissioned for an oil and gas company in the Middle East. Because of its low life cycle cost due to improved maintainability and versatility [6], this RTU is also attractive for use in many other industries. In addition to its primary roles of monitoring, reporting and control, the designer can programme the RTU to implement complicated algorithms (like flow computations) to suit different applications.

References

[1] H.L. Smith and W.R. Block, RTUs slave for supervisory systems, IEEE Comput. Applic. Power (January 1993) 27-32.

[2] IEEE Tutorial Course - - Fundamentals of Supervisory Systems, 94 EH0392-1 PWR.

[3] IEEE Recommended Practice for Master/Remote Supervisory Control and Data Acquisition (SCADA) Communications, IEEE Std 999-1992.

[4] D.J. Gaushell and W.R. Block, SCADA communication techniques and standards, IEEE Comput. Applic. Power (July 1993) 45-50.

[5] Measurement of fluid flow by means of pressure differential devices, ISO 5167-1: 1991(E), International Standards Organisation, 1991.

[6] IEEE Tutorial Course - - Fundamentals of Supervisory Control Systems, 81 EHO188-3-PWR.

" G.T. Heng received his BEng (Hans) and MEng from the National University of Singa- pore, in 1985 and 1990 respectively. He had worked for several years with the Ministry of Defence (Singapore) and was responsible for the instrumentation and flight test data acquisition systems for all flight test pro- grammes in the Air Force. Subsequently he joined a Canadian company to design the software for the company's range of PC-based and

, microcontroller-based RTUs. He was also responsible for the implementation, commissioning and maintenance of SCADA systems. He is currently a lecturer with the Nanyang Technological University and his present research interests include Biomedical Engineering and distributed monitoring and control systems.

Documents

Microcomputer-based remote terminal unit for a SCADA system