development of a novel scada system for laboratory testingserver3.eca.ir/isi/forum/4.pdf ·...

g

a

-nts testuslyconceptres andver, thegrammingato the

ia a localCADA

standard

ISATRANSACTIONS®

ISA Transactions 43~2004! 477–490

Development of a novel SCADA system for laboratory testin

M. Patel,a,* G. R. Cole,b T. L. Pryor,b N. A. WilmotaaAustralian Cooperative Research Centre for Renewable Energy Ltd. (ACRE), Murdoch University, Perth 6150, Australi

bMurdoch University Energy Research Institute (MUERI), South Street, Murdoch University, Perth 6150, Australia

~Received 31 July 2003; accepted 28 February 2004!

Abstract

This document summarizes the supervisory control and data acquisition~SCADA! system that allows communication with, and controlling the output of, various I/O devices in the renewable energy systems and componefacility RESLab. This SCADA system differs from traditional SCADA systems in that it supports a continuochanging operating environment depending on the test to be performed. The SCADA System is based on theof having one Master I/O Server and multiple client computer systems. This paper describes the main featuadvantages of this dynamic SCADA system, the connections of various field devices to the master I/O serdevice servers, and numerous software features used in the system. The system is based on the graphical prolanguage ‘‘LabVIEW’’ and its ‘‘Datalogging and Supervisory Control’’~DSC! module. The DSC module supportsreal-time database called the ‘‘tag engine,’’ which performs the I/O operations with all field devices attachedmaster I/O server and communications with the other tag engines running on the client computers connected varea network. Generic and detailed communication block diagrams illustrating the hierarchical structure of this Ssystem are presented. The flow diagram outlining a complete test performed using this system in one of itsconfigurations is described. © 2004 ISA—The Instrumentation, Systems, and Automation Society.

Keywords: SCADA; RESLab; LabVIEW DSC module; Renewable energy systems testing

nmscht

uctre-utgeere

gi-

ys inys-s-ilyfa-s.l-areen

-eldcli-

1. Introduction

1.1. The SCADA system

RESLab, previously known as ACRELab, is aAustralian National Renewable Energy systeand components test facility located at MurdoUniversity in Western Australia. At presenRESLab provides design, testing, training, proddevelopment, and certification services for thenewable energy industry. More details aboRESLab and the specification of small and larhybrid system test beds can be found elsewh

*Corresponding author. Tel.:~61! 08 9360 6301; fax:~61! 08 9310 6094.E-mail address:[email protected]

0019-0578/2004/$ - see front matter © 2004 ISA—The Instru

@1#. One of the major requirements of this testinfacility was a supervisory control and data acqusition ~SCADA! system allowing communicationwith and control of the output of various industrstandard I/O devices and programmable deviceorder to perform tests on renewable energy stems and components. This overall SCADA sytem was expected to be user friendly and easable to integrate additional devices as the testcility expands to undertake other testing activitieA number of traditional SCADA systems deveoped for various applications and having similarchitectures, with one or more servers, have bdescribed previously @2–4#. Typically in aSCADA system the data flow is limited to predefined paths, which are based on the fixed ficonnections between hardware and master or

mentation, Systems, and Automation Society.

h

l

ra-

-

-

heedon-ta-n-

s,a

deally

ofheelyin

sir-

ell

de-er-n-

aof

hisa

/Ou-thehed

dtsinmO/O,ei-ft-heel

nta

heedrs,nt-n,nda

heto

lo-testeedatggsof

pa-ra--

478 Patel, Cole, Pryor, Wilmot / ISA Transactions 43 (2004) 477–490

Nomenclautre

AB Allen BradleyACRE Australian Cooperative Researc

Center for Renewable EnergyCPU Central Processing UnitDAQ Data AcquisitionDDE Dynamic Data ExchangeDH1 Data Highway PlusDSC Datalogging and Supervisory ControHMI Human Machine InterfaceGPIB General Purpose Interface BusI/O Input/OutputIA Industrial AutomationLabVIEW Laboratory Virtual Instruments Engi-

neering WorkbenchNIDAQ National Instruments Data Acquisi-

tionOLE Object Linking and EmbeddingOPC OLE for Process ControlPCI Peripheral Component InterconnectPSC Power Supply ControllerPXI PCI eXtension for InstrumentationRESLab Renewable Energy Systems Labo

toryRS Rockwell SoftwareSCADA Supervisory Control And Data acqui

sition SystemSCPI Standard Commands for Program

mable InstrumentsSLC Small Logic ControllerSMS Short Messaging Service

ent station. However, it should be noted that trequirements of a SCADA system for specializapplications such as petrochemical industries, ctrol towers at international airports, and power stions, are sophisticated enough to clearly differetiate them from traditional SCADA systemwhich often have uni-directional dataflow andconfiguration of static nature.

In the SCADA system described here, a wirange of devices and components are physicconnected to either the master I/O server or anythe client computers. The software controlling toutput of these devices and the dataflow is rarthe same for different types of tests carried outthe laboratory. Therefore it was considered deable that the code be developed in-house~withinthe laboratory! to minimize the development timand maximize utility. It was envisaged that a

these challenges could only be handled via thevelopment of a reasonably sophisticated, but vsatile, and nontraditional SCADA system. In cotrast to the traditional SCADA system based onpre-configured hardware setup the amountchange in the dataflow on a regular basis in tlaboratory setting is very large. For this reasonlarge proportion of the system architecture or Ispecific code is dynamic and not fixed. This docment describes the hierarchical architecture ofdeveloped SCADA system and a summary of tsoftware used to perform a wide variety of anregularly changing tasks.

As shown in Fig. 1 this SCADA system is baseon the concept of one server and multiple clienarchitecture, only one client computer is shownthis figure as an example. This SCADA systeallows communication among the master I/server computer, client computers, and all the Idevices in RESLab~e.g., SLC, dc power supplypower monitors!. This system structure allows thinput and output of all the I/O devices to be drectly accessed and controlled. The primary soware development environment used for both tserver and client computers is LabVIEW with thadditional Datalogging Supervisory Contro~DSC! module. Virtually all of the communicationbetween either the master I/O server or a cliemachine and I/O devices is then handled viareal-time database known as the ‘‘tag engine.’’ Trequired I/O information can then also be sharwith the tag engines on the rest of the computewhich allows users to perform multiple tests odifferent client machines simultaneously. The doted lines in Fig. 1 represent manual interactiowhile the solid lines represent data and commaflow. The client computer is also connected tofew of the I/O devices through device servers; tdata acquired from these I/O devices is passedthe master database through a client computercal database. The test engineer supplies theinputs using a LabVIEW based HMI during thtest execution. The test specific data are loggwith date and time steps in a preconfigured formon the client computer, which is actually executinthe test, while the master I/O server computer loany events, alarms, or errors reported by anythe software and I/O devices. Several selectedrameters~e.g., status of load bank, diesel genetor, and grid breaker! are also logged on the mas

479Patel, Cole, Pryor, Wilmot / ISA Transactions 43 (2004) 477–490

Fig. 1. SCADA system overall structure.

leeaenificut-tetoI/Oor

ingt

atein

ndas

rs;en-e

se,cesin

’’ac-d-stus

ni-m

--r

r-l

a-

eo-mithe

d-

ter I/O server computer hard disk. This flexibdata sharing arrangement makes it possible to rthe same parameters independently on differclient machines at the same time. The test speccode from a client computer can also set the oput of any I/O device by sending an appropriavalue via the client computer local tag enginethe master I/O server tag engine. The masterserver computer performs the following majtasks:

• acts as a central database for exchangdata with all the I/O devices within the tesfacility;

• maintains communication with all the I/Odevices, generates an error if an appropriresponse is not received within a certatime period and records that error;

• controls the output of various devices as awhen requested by the client computers orpart of an error handling routine~in the casewhere device servers report an error!;

• responds to the requests of client compute• reports and logs the alarms and events g

erated by the software and I/O devicservers/drivers;

• keeps track of the resources currently in utheir calibration status and maintenanrecords. Via software interlock mechanismit restricts the access of devices currently

dt

use ~i.e., performs the task of ‘‘allocationand de-allocation of the system resources!;

• logs the selected parameters for the dataquisition system reliability analysis, anlong term trending of a few key system parameters~e.g., outputs reported by varioutemperature sensors, communication staof various devices servers!.

The main devices and the associated commucation methods employed in this SCADA systeare as follows:

• An Allen-Bradley SLC 5/04 processor module is connected to an Allen Bradley 1784KTx card located in the master I/O Servecomputer using theDH1 communicationprotocols. The Lookout OPC Server drivefor the Allen Bradley SLC allows the LabVIEW Datalogging and Supervisory ControModule Tag Engine to exchange SLC prameters’ related information with the ABcard @5#.

• Two Crompton Integra power monitors arconnected to a serial port using Modbus prtocol via an RS485 interface. The data frothese power monitors can be exchanged wthe LabVIEW DSC Tag Engine using thModbus OPC lookout drivers.

• The Johnson Controls DX-9100 ExtendeDigital Controller of the environment cham

-

r

-inhe

-Oe-

the

e

tabd

rly

--

-s

m-dan,ent

w-nd

i-dmri-

Bon

-ct-it

s-

a-

eeh

dheton-and. Itred

ap-I

or-

ts,e--ed

i-isa-

n-u-isen-

rea-teratay


ber is connected to a serial port~via RS485interface! using the Metasys DX9100 protocols on an N2 bus.

• The controller of the Powerten dc powesupply is connected to a serial port~via anRS232 interface! through LabVIEW codedeveloped using the SCPI language.

• An Agilent Technologies solar array simulator is connected to a GPIB card locatedthe master I/O server computer using tSCPI language on the GPIB bus.

• The NIDAQ hardware, NI 6035E, is connected to the PXI device in the master I/server computer through LabVIEW code dveloped using the NIDAQ protocols.

1.2. Software/Interface used in the SCADAsystem

The various software packages used inSCADA system are briefly described below.

• Allen-Bradley Rockwell Software is usedto communicate with, and program, thAllen-Bradley SLC. A number of softwarepackages were used to connect and to eslish communication between the SLC anthe master I/O server computer in the eastages of system development.RS LinxOEM ~version 2.1! was used for communication between the SLC and an AllenBradley Industrial Automation ServerinLookout. Advice from National Instrumentsuggested that this method~Industrial Auto-mation Server!would not be maintained infuture updates of the software. The recomendation was to shift over to the preferremethod of OPC, which is fast becomingde-facto standard method of communicatioand is used by a wide range of measuremand control software products@5#. RS Logix500 ~version 2.57! is used to program anddownload a program on the AB SLC.RSPower~WINtelligent LINX, version 5.0! is astandalone package running on a PC alloing the user to communicate, configure adownload information from the Allen-Bradley power monitors. It contains a varety of utilities and functionalities associatewith the analysis of the data obtained frothe power monitors. It is not required focommunications between the power montors and the SLC. None of the above Asoftware is used during the normal operatiof the test facility.

-

• LabVIEW Datalogging & SupervisoryControl Module ~version 6.0.2! co-ordinates all the I/O activities within theRESLab facility from the master I/O computer. The National Instruments produLabVIEW is a graphical programming language. It incorporates features that makepossible to use LabVIEW as a SCADA sytem development environment. LabVIEWsupports a real-time database known asLabVIEW DSC Tag Engine. One of the applications of this tag engine called ‘‘devicserver’’ can communicate with a wide rangof standard industry I/O instruments througits support for OPC Applications, DDE, anIA device servers. The tag engine has tability to start and stop device servers,scale and initialize parameter values, to geerate, process and log alarms and events,to log data to a Citadel historical databaseis also possible to use a third party hardwamanufacturer server for uniquely configurecustom devices@6#. Unlike other SCADApackages the LabVIEW HMI providescomplete programming environment to suport the communications between the HMand the tag engine. The LabVIEW code fgeneric activities like processing and logging of data, setting the load bank outpuspecifying and recording the test inputs, rporting and logging of alarms, real-time display, and sharing of the test data can be usby various tests.

• Lookout Protocol Drivers OPC Server~version 4.5! provides the low level driverinterface ~for basic communications! be-tween the LabVIEW DSC module and varous industry standard I/O devices. Thmethod is being used for the normal opertion of the system.

• Server Explorer ~version 2.4! provides a di-rect access to items of a device server cofigured in Lookout and the associated instrment from a user friendly interface. Thisessentially a simple and primitive interfacto test and debug communication with a cofigured device without any programming.

2. Communication within the SCADA system

Fig. 2 shows the detailed hierarchical structuof the RESLab SCADA system in a communiction block diagram. The tag engine of the masI/O server computer continuously exchanges dwith the I/O devices connected to it locall


Fig. 2. RESLab SCADA system communication block diagram.

tedeex-on-in-OI/Oil-atxi-hetsenausble-

entmend

on-inn-r-

ist-

aten-nt

lo-et

og-t ofntthee-li-

the

orsstopra-er

s,inlo-

rsre

n a

n-a

through a range of device servers via designahardware and associated software using agrprotocols. Similarly, various client computers echange data with various I/O devices they are cnected to, and continuously pass the requiredformation to the tag engine of the master I/server computer. The tag engine of the masterserver computer makes this I/O information avaable to the tag engines of the client computersrequests. Under typical system operation appromately 500 data points are being monitored in ttest facility and over 90% of these I/O data poinare passed through the AB SLC. Additionally thmaster I/O server computer maintains several alog and digital memory tags for miscellaneopurposes for use by software, which is responsifor a range of overall system functionality. Examples include interlocks, resource managemalarms, and system usage. Out of a total of so600 tags ~measured/reported parameters acalculated/memory parameters! on the master I/Oserver computer, only a selection of tags are ctinuously exchanged with the client computersorder to keep the network traffic within a reasoable limit. These are the minimum required to peform a test on the client computer. Within thframework, the system allows any client compuers to access any I/O information at a desired rindependent of the other client computer tag egines, all running simultaneously. Once a clie

d

-

,

computer tag engine receives the information,cally or from the master I/O server tag enginwhich may be originally coming from other cliencomputer~s! tag engine~s!, the local LabVIEWcode developed for scanning, processing and lging the data accesses this information as parthe test being performed on that particular cliecomputer. The test specific code executing onclient computer can set the output of any I/O dvice by sending the appropriate value from the cent tag engine to the target I/O device throughmaster I/O server computer tag engine.

2.1. Communications with the I/O devices

The SLC polls the local analog and digital I/Omodules which in turn are connected to sensreading temperatures, status of the emergencybutton and the fuel consumed by a diesel genetor. The SLC also contains a remote I/O scannwhich acquires data from the AB power monitorremote analog, and digital I/O modules. Theseturn are connected to field devices in separatecations within the test facility. The power monitoand remote digital and analog I/O modules adaisy chained to the AB SLC~i.e., they are con-nected in series to the same master device oproprietary network!. The individual power moni-tors read the power quality data from a diesel geerator controller, a programmable load bank,

tegeanker

m-thebleesis

heg

x-Cer.eshe

terbe-al

er.ers

edentheen

-i-r

Ors,lesdemheotetheem-S-gh

edas-el 1

or

d

enter

erverrt.-oler-

I/Ohee.re

esm-sts

aty

00ol

edre-

ice

gecaisterb-n-

r

ge,


wind turbine controller, and the grid. The remoanalog I/O modules read the output from voltaand current transducers attached to a battery ba dc power supply, and a battery charger, and thmocouples measuring the pilot battery cell teperatures. The remote digital I/O modules readoutput status from a single-phase programmaload bank, output status from various dc sourcand the configuration of the battery banks. Thinformation is passed to the AB card using tDH-485 interface and then to the Lookout usinthe DH1 network protocols. The Lookout OPCServer, using a driver for AB devices, then echanges this information with the LabVIEW DSTag Engine of the master I/O server computSimilarly communication between other devicand a tag engine can be visualized in Fig. 2. Tfirst layer below the master I/O server compuDSC tag engine is the device servers/drivers,low which is a layer associated with the physicconnection of the I/O devices with the computThe next layer represents the device controll~which actually acquire the data!, and the lowestlayer lists the physical devices. A more detaildescription concerning communication betweeach of these six major types of devices andmaster I/O server computer tag engine is givbelow.

2.1.1. SLCAn Allen Bradley SLC 5/04 is directly con

nected to the 1784-KTx Allen Bradley communcations card~plugged into the master I/O servecomputer! via a three-wire cable. The remote I/scanner is connected to five AB power monitoand several remote analog and digital I/O moduon a daisy chained network. The ladder logic coof the SLC maps any relevant information frothe devices remotely connected to the SLC. Tcommunication parameters of the various remdevices are configured by the SLC as part ofinitialization process of the SLC program. ThSLC 5/04 CPU can be accessed through two comunications channels: via channel 0 through R232 based protocols, and via channel 1 throuDH1 ~an RS 485 based! protocols from the ABcard. During normal operation channel 1 is usfor communication between the SLC and the mter I/O server computer. However, both of thchannels can be used simultaneously, channefor the normal communication, and channel 0 f

,-

debugging~i.e., to access the SLC ladder logic anto monitor the critical registers!. The data via theKTx card can be accessed using several differtypes of software such as Lookout OPC Servdriver, RSLinx, RSLogix.

2.1.2. Power monitorTwo single phase Crompton Integra pow

monitors are connected to the maser I/O sercomputer via an RS485 bus through a serial poThe power monitor driver configuration parameters were derived from the Modbus protocmanual@7#. The tag engine can access the powmonitors output via a Modbus driver in the Lookout OPC Server.

2.1.3. DX-9100 controllerThe DX-9100 extended digital controller from

Johnson Controls is connected to the masterserver computer through a serial port using tMetasys DX9100 protocol via an RS485 interfacThe DX-9100 controller measures temperatuand humidity and using a PID algorithm operatthe actuators to maintain the environmental chaber at desired conditions. This controller consiof numerous programmable function modules,programmable control logic module, and a varieof date and time functions@8#. LabVIEW codewas developed to communicate with the DX-91controller using the Metasys N2 System Protocand the Metasys DX9100 Protocol, the requircommunication protocol for accessing data thatside in the devices on an N2 network@9,10#. Inthis case, there is just the single DX-9100 devon an N2 network.

2.1.4. dc power supplyThe Powerten dc power supply output volta

and current are controlled by a Delta ElectroniPSC controller. This power supply controllerconnected to the master I/O server computhrough an RS232 serial port. The required LaVIEW code was developed using the SCPI laguage@11#.

2.1.5. Solar array simulatorThe output of the Agilent Technologies Sola

Array Simulator is controlled via a GPIB bus fromthe client computer@12#. The required LabVIEWcode was developed using the SCPI langua

r-

e

ec-p-ion

putb-tom

r

/Or-C

onof

iledleedterrveatasreheeseI/Ors.u-

he-m

rea

eghne

ex-na-

t-tagts

ly

of

se-

ehehe

re-r-hea

ione-in-oraise-

sal-ro-utb--dr-e-n

al-etsynt

. Itayc

to-s-ofxt


which maintains communication with the solar aray simulator using a VXI instrument driver.

2.1.6. DAQ hardwareThe National Instruments DAQ hardwar

~NIDAQ 6035E I/O device! is connected to thePXI card in the computer through LabVIEW coddeveloped using the NIDAQ drivers. Data are aquired from the device following the standard aproach as outlined in the supplied documentatfor the device @13#. The NIDAQ hardware isphysically attached to and thus controls the outof the dc loads through relays. Additional LaVIEW code was written to provide an interfacethe tag engine, thus allowing the SCADA systeto gain access and control these functions.

2.2. Communication between master I/O serveand client computer tag engines

Network communication between the master Iserver and client computers, from a SCADA pespective, is achieved using the LabVIEW DSModule. This results in tag engines runningeach of the computers. Configuration and set upthese engines was relatively standard, as detain the documentation supplied with this modu@6#. Given the hierarchical structure adoptwithin the laboratory, the tag engine on the masI/O server computer was designated as the seor ‘‘master tag engine.’’ This typically means thtags on this machine are ‘‘master’’ tags, wherethe majority of tags on the client computers aoften only copies or refer back to the tag on tmaster I/O computer. That is, there are two typof SCADA configuration files which define thtags for each engine, one is for the mastercomputer and the other for the client computeThe major differences between these two configration files being the read/write privileges and tlocation of ‘‘master’’ tags. The SCADA configuration files include all the required tags or systeI/O parameter related information~e.g., parametename, device name, address, update rate, dband, type of tag, unit, scaling, and alarm limits!.They define what and how information is to bexchanged among various tag engines. Althouthe setup described in this paper has only oserver, the system is extremely versatile. Forample, ‘‘the Server LabVIEW DSC module caalso perform as a DSC client and access inform

r

d

tion from different DSC module Server compuers’’ @6#. These features enable access to thevalues corresponding to various monitoring poinin the master I/O server computer~including allthe monitoring points of client computers directconnected to various I/O devices! via any of theremote client computers. The inbuilt featuresthe LabVIEW DSC module~i.e., the tag engine!,which uses the Logos networking protocol, allowthe exchange of analog and digital information btween the server and client tag engines.

3. Features of this SCADA system

Following is an itemized list pointing out somof the more important and salient features of tsetup and operation of the laboratory, from tperspective of the developed SCADA system.

• The system interlocks prevent access ofsources in order to avoid accidentally interupting a test in operation and ensures tsafety of the overall system. Each timenew test is selected the system configuratis checked thoroughly, and the required rsources access is requested. Similarly, ifdividual components need to be usedsome maintenance is required, it is onlymatter of first checking that the resourceavailable for use and then allocating the rsource to that task.

• Much of the developed LabVIEW code ibased on a state machine design, whichlows the user to change the state of the pgram or to stop the program easily withocrashing the program. The generic LaVIEW code developed for ‘‘defining and recording the test input parameters’’ an‘‘scanning, processing and logging the aveage, minimum, maximum, and standard dviation of various parameters’’ is used ivarious tests without any modifications.

• In each time step the system reads new vues from the user specified profiles and sthe load bank output, simulates PV arraoutput using the solar radiation and ambietemperature during the course of the testis possible to simulate the specified PV arroutput using two different devices, the dpower supply or the solar array simulator.

• The program code was developed to aumatically record pre-configured text mesages to a log file at every major changethe test status. In addition it records the te

Iasingof-

in

uts-

ebelts

ofo--

emismf

t-u-e

ut

teingbeteneeryrt-

-i-e-ewndres.o-my

r-

a

ali-ci--dplee.fwre

-l-

i-

e-e

e

the/O

f.

l-

ere-

in

-

an-rs

/yf-

a-

se-ac--


~describing the special events! supplied us-ing the keyboard through a LabVIEW HMduring the course of the test. The code wdeveloped to suspend the data processduring the load transitions at the changetime steps. This configuration and programming feature provides needed versatilitythe processing of the data.

• The system records the test specific inp~PV array, battery bank, and inverter parameters! to allow the repetition of tests with thsame inputs. This test input data coulduseful for the detailed analysis of test resuat a later stage.

• The system is able to handle a wide rangeerrors and safely shutdown various compnents in reliable and effective ways recommended by the manufacturers. The systsupports a sophisticated range of mechanfor integration, reporting and recording oerrors, events, and alarms.

• LabVIEW code was developed incorporaing the required server features for commnication with the device controllers for thOPC Lookout noncompliant devices~the de-vices which do not have a standard LookoProtocol driver for the OPC server!.

• The system is flexible enough to integraadditional industry standard I/O devicesthe existing system. To date, the existinsystem has allowed a range of tests toperformed including those on hybrid remoarea power supply systems, stand-alopower systems, solar home systems, battcharge controllers, and grid connect inveers.

• The user friendly and descriptive LabVIEWHMI’s @shown in Figs. 4~a!–~d!# and theoverall SCADA system design allows nonLabVIEW users to perform tests with minmal overview of the test and program dsign. The system is easily extended as ndevices and instruments are introduced aintegrated into the laboratory, or tests aperformed using new test methodologieThis approach provides a user friendly, sphisticated, and cost effective DAQ systeideal for continuously changing laboratortesting applications.

3.1. Nontraditional features

• The developed SCADA system with its hiearchical architecture~illustrated in Fig. 2!and design is able to control and integrate

wide range of industrial I/O devices fromcentralized server computer and various cent computers, for example, an SLC, dpower supplies, and power monitors. Typcally, a number of LabVIEW DSC tag engines allow the I/O related information anprocessed data to be accessed from multiclient computers simultaneously in real tim

• Although the underlying basic structure othe SCADA system and associated data floremains the same, when different tests aperformed changes can be expected in:+ software code used on various client computers~e.g., they could be performing deveopment, debugging or execution task!,+ total number of client computers used,+ total number of I/O devices used,+ number of I/O devices connected to varous client computers,+ response of the master I/O server on rceiving a specific error or warning from thSCADA system,+ the scan time and log time used by thSCADA system,+ the data being processed and logged onclient computers as well as on the master Iserver computer,+ operating mode in which the outputs ovarious different I/O devices are controlled

• It is possible to perform multiple tests simutaneously using the large~three-phase! andsmall ~single-phase! system test beds withinthe test facility with the constraint that thestests do not require the same systemsources~i.e., I/O device!.

• Different inbuilt features of the master I/Oserver may be activated or deactivatedreal time as required~for, e.g., access to aspecific device!,

• A client computer performing local highspeed data acquisition~up to 10-kHz rate!can synchronize its data capturing withsignal triggered by a specific event, from aother one of the SCADA system computeinvolved in the test.

• Any of the client computers’ operationfunctionality can be altered in real time bselecting the appropriate code without afecting the rest of the SCADA system opertion.

• A client computer performing the test doethe scanning, processing, and logging of slected parameters. These data could bequired through a local I/O directly, or a re

nin

s

ofrer-

lof

a-reto-em

toithur-n

stckto

e

of

hethateronis

hepo-


mote I/O through tag engines running oother SCADA system computers involvedthe test.

• Unlike in the traditional SCADA systemthe operating screens~user interface win-dows! on the master I/O server and anythe client computers within this system adifferent depending on the task being peformed by the computer.

4. A typical test performed using the SCADAsystem

Fig. 3 illustrates the flow diagram of a typicatest performed using the SCADA system in oneits typical operating environments. The flow digram gives an overview of the steps, which aexecuted sequentially during the complete aumated hybrid remote area power supply syst

performance test. The main aim of this test isdetermine the system fuel efficiency together wthe diesel generator and battery performance, ding the operation of the hybrid system over aextended period of time. As evident from the firpart of Fig. 3, when a test is first selected, a cheis made as to whether all the resources requiredperform that test are available or not. If any of threquired resources is unavailable~being already inuse, or unavailable due to breakdown, expirycalibration, or routine service checks! the programinforms the operator and then terminates. If all tresources are available, they are allocated toparticular test on the particular client computand appropriate indicators are manually placedvarious switchboard components. The next stepto test the set up configuration~checking of thecorrect circuit diagram of the test system and toperational status of various test system com

Fig. 3. Hybrid RAPS system performance test flow chart.


Fig. 3. ~Continued.!

lofst-

u-

ing-

nents!, which involves a combination of manua~e.g., the position of the fuel valve, the levelfuel in the storage tank! and automatic check~e.g., position of all the circuit breakers, the ba

tery bank terminal voltage, the status of commnication with various I/O devices!. The test systemis then energized and the system preconditionis performed, if required. The following step re


Fig. 4. ~a!–~d! LabVIEW HMI’s indicating various aspects of testing and real-time monitoring.


Fig. 4. ~Continued.!

utseyhe

wesnpsadsepis

her-

ndiveur-er

t thagl-

dstnly

er ofn-antesthes atsre-e-cebeer-ov-

te-

n

rt-n-po-lAof

ofu-

endt-

s-tee-t-ion

up-ch

nresgerk

nA

.heity.n-

-

ry

C-al

W9.


quests the user to specify the test specific inpand profiles, and if all these inputs are valid thare recorded in a configuration file. This marks tend of test initialization phase.

As indicated in the second part of the flodiagram in Fig. 3, the actual test commencafter the completion of the test initializatiophase. The maximum number of time steand maximum number of scans are reand the first step of the ‘‘time step module’’ iinitiated. In the time step module the time stcounter is initialized and if the present time stepless than the maximum time step number(N isless than or equal toNmax), the programmable loadbank is set to the next load value read from tprofile. The simulated PV array output is detemined from the next values of solar radiation aambient temperature read from their respectprofiles, and the dc power supply voltage and crent are set to supply that calculated output pow~‘‘simulated PV array output’’!. After that the pro-gram starts scanning the selected parameters arequired rate, processes and updates the averminimum, maximum, and standard deviation vaues. At the end of the first time stamp(T becomesgreater than or equal toTmax), the data are loggedto a log file in a specific format. This is precedeby a few lines of comments describing the tespecific details. For subsequent time periods othe data are appended to the log file. This timstep module is repeated for the required numbetimes by stepping through the specified profile util the last step. At the end of the test the user cselect to repeat the test, and in that case theinputs need to be specified. This step marksend of the actual test and the program enter‘‘post conditioning’’ phase. When the user selecto end the test the system is run through thequired post conditioning routine before dallocating all the resources. Thus these resourare now available for any other test required toconducted in the laboratory. This generic and usfriendly interface allows non-LabVIEW users tcarry out the test using this SCADA system. Seeral LabVIEW HMI windows displayed on thescreen during the course of the test are presenin Figs. 4~a!–~d!. The brief description accompanying these LabVIEW HMI’s gives an overviewof the purpose of the window and the informatiodisplayed on it.

ee,

t

s

d

5. Conclusions

The paper describes a SCADA system suppoing the continuously changing operating enviroment in a renewable energy systems and comnents test facility. A number of nontraditionafeatures of this SCADA system are highlighted.description of the main features and advantagesthis dynamic SCADA system, the integrationvarious field I/O devices, and an overview of nmerous software features~mainly LabVIEW andits Datalogging and Supervisory Control modul!used in the system are included. The generic adetailed communication block diagrams illustraing the hierarchical structure of this SCADA sytem, and the flow diagram outlining a completest performed using this system are also dscribed. This SCADA system is currently operaing, and is also in a state of constant expansand development.

Acknowledgments

The work described in this paper has been sported by the Australian Cooperative ResearCenter for Renewable Energy Ltd.~ACRE!.ACRE’s activities are funded by the AustraliaCommonwealth’s Cooperative Research CentProgram. The authors would like to acknowledthe support of Paul Cornes, Bob Brockman, MaTrotman ~ICON Technologies!, and the NationalInstruments support team for their contributioand feedback in the development of this SCADsystem.

References

@1# Pryor, T. L., Spooner, E. S., Wilmot, N. W., Cole, GC., Sharma, H., and Patel, M., Current Activities at tACRELab Renewable Energy Systems Test FacilIn Proceedings of the ISES 2001 Solar World Cogress, Adelaide, Australia, 2001, pp. 1903–1910.

@2# Dieu, B., Application of the SCADA system in wastewater treatment plants. ISA Trans.40, 267–281~2001!.

@3# Cardoso, F. J. A., A universal system for laboratodata acquisition and control. IEEE Trans. Nucl. Sci.47~2!, 154–157~2000!.

@4# Singlachar, R. and Mukherjee, B., An advanced PPLC-based SCADA system for a commercial mediccyclotron. Nucl. Instrum. Methods Phys. Res. A399,396–406~1997!.

@5# National Instruments, Chapter-3 Servers, LabVIEDSC Module Developer’s Manual, Texas, USA, 199

e--

ngK,

x-,

eci-

ifi-

l-

y

er

-

e

sof-

--or-He ithe

.ns-

-

-

s-r

-s

r

--

d

,-

s

-

to


@6# National Instruments, Chapter-9 Networking and Dploying Applications, LabVIEW DSC Module Developer’s Manual, Texas, USA, 2000.

@7# Crompton Instruments Ltd, Installation and OperatiInstructions, Crompton Integra 2000, Essex, U2000.

@8# Johnson Controls, Technical Bulletin–DX-9100 Etended Digital Controller, Inc. Milwaukee, WisconsinUSA, 2003.

@9# Johnson Controls, Metasys N2 System Protocol Spfication, Milwaukee, WI, USA, 1996.

@10# Johnson Controls, Metasys DX9100 Protocol Speccation, Milwaukee, WI, USA, 1994.

@11# Delta Electronica BV, PSC232 Power Supply Controler Manual, Zierikzee, Netherlands, 1999.

@12# Hewlett Packard, Operating guide for Solar ArraSimulator E4351B, California, USA, 1997.

@13# National Instruments, DAQ 6034E/6035E UsManual, Texas, USA, 1999.

Mehul Patel is currentlyworking toward a Ph.D. degreein renewable energy engineering at Murdoch University. Hereceived his Bachelor degrein mechanical engineeringfrom Gujarat University, Indiain 1999. His research includethe performance assessmentphotovoltaic array based standalone as well as hybrid remotearea power supply~RAPS!systems. His work interests extend to developing and main

taining the SCADA system for laboratory investigation of the perfmance of RAPS systems using real and simulated power sources.a recipient of the ACRE Postgraduate Student Scholarship fromAustralian Government.

s

Graeme Cole is the SCADAsystem developer at RESLabHe has extensive experience ihardware and software systemassociated with embedded, industrial and SCADA like com-puter systems, including datalogging, control systems, sig-nal processing, and conditioning and LabVIEW program-ming. Currently, he is anassociate professor in engineering at Murdoch University.

Trevor Pryor is RESLab’sResearch manager. He habeen involved in the area of renewable energy research foover 25 years and is currentlyDirector of the Murdoch Uni-versity Energy Research Institute. Current research interestinclude the simulation andanalysis of remote area powesupply systems, the monitoringand evaluation of renewableenergy systems, energy management, and energy educa

tion.

Nigel Wilmot is RESLab’smanager. He has been involvewith renewable energy re-search since 1991 working inseveral project areas includingremote area power suppliestesting and standards development, performance monitoringof systems and component~e.g., wind turbine and photo-voltaic!, and vaccine refrigera-tion. He also has been an information officer for renewableenergy systems, which in-

volved the provision of technical advice and consulting servicesnumerous projects.

development of a novel scada system for laboratory testingserver3.eca.ir/isi/forum/4.pdf ·...

Documents