4e-Ol 1
Copyright © 1996 IFAC . 13th Triennial World Congress. San Franclsco, USA
SIMULATION OF SMALL HYDROPOWER STATIONS FOR OPERATOR TRAINING Xiaobing Qiu •. 1, Adolf H. Glattfelder', Waiter Schaufelberger' and Rolf Widmer **
• A "tomatic Control Laboratory, Swiss Federal Institute of Technology ZUrich, ETH Zentrum, CH-809E Zurich, Switzerland. E-mail:
[email protected] ** Swiss Center for Development Cooperation in Technology and Management, Vadianstr. 42, CH-9000, SI. Galle"
Abstract. Hydropower is important for many developing countries. Small hydropower stations can be manufactured and operated in the countries by local personnel. Training of this personnel for operating the stations under different operating conditions is becoming vital. At ETH ZUrich, together with the Swiss Center for Development Cooperation in Technology and Management, we are developing a generally available simulator for operator training. The simulator must be easy to use in teaching. No programming, only configuring should be required. Oberon, an object-oriented programming language and a modular! extensible operating system developed by N. Wirth and J. Gutknecht at ETH Zurich, is used os the basis for the simulator. The modelling and simulation of small hydropower stations is described in some detail. Keywords. Automation, Developing countries, Operator training! Power station control, Simulation.
L INTRODUCTION Small hydropower stations with power in the region of 100 kW are used in many developing countries for electric power supply to small communities (Veltrop, 1992). Such a station may be built and operated by a family or a small firm. These small stations may be connected to other stations or to a large grid and arc therefore operated under very different operating conditions. Training of the operators is important as they have to cope with the different operating conditions and to understand the highly nonlinear behaviour of their plants. Based on this, 1 Partially supported by the Pao Scholarship for Chinese Students Studying Abroad for her first year of study in Switzerland
we decided to implement a simple portable simulator running on generally available personal computers (IBM compatibles, Macintosh) with a good graphical user interface and programmed in a system that is freely available without license fees. Oberon is an object-oriented programming language and a modular, extensible operating system developed by N. Wirth and J. Gutknecht at ETH Zurich (Mossenbock, 1993; Reiser, 1991; Reiser and Wirth! 1992; Wirth and Gutknecht, 1992) fulfilling these needs. An overview can be found in (Qiu and Schaufelberger, 1994). Oberon and Oberon-2 are object-oriented programming languages, providing mechanisms for encapsulation of da.ta, infor-
950
mation hiding, type extension (inheritance), polymorphism and dynamic binding. In true object-oriented style, the basic system is extended by a few modules to become a simulator for continuous time systems. The hydropower simulation is just one application of this general simula.tor for training. In [I. similar way, a training program for anaesthesia personnel was also developed
at our lab. Source and object code of the simulator and the hydropower simulation are made publicly available. This allows the generation of similar simulators for other purposes.
2. OBERON AND OBERON-2
evolution called Oberun system 3 (Gutknecht, 1994) with Gadgets (Marais, 1995). Gadgets is a graphical user interface management system for Oberon System 3. It consists of a set of end-user objects called gadgets for building graphical user interfaces at run-time. With the existing gadgets, e.g. check box, push button, radio buttOD, slider, text field, panel, iconizcr, graphical user interfaces can be developed very easily. Our simulator is
b..ed on the Oberon system 3. The Oberon systems are available for downloading from the server of the computer science department of ETH.
2.2 Simulation in Oberon and Oberon-I!
2.1 Programming in Oberon and Oberon-2
Two modules have been added to Oberon to develop
Oberon (1988) is the latest descendant in the family of languages whose root is Algol 60 (1960), and whose other members are Pascal (1970) , and Modula.-2 (1979).
systems. Tbe two modules are available in source code and are described here by giving their definition modules. These modules are automatically generated from the object files by a browser. They have been edited for
the basic environment into a simulator for continuous
The important new feature introduced in Oberon is the
type extension. Oberon-2 is a small and fully upward compatible ext ension of Oberon proper. The major addition of Oberon-2 is the type-bound procedure that
easier reading.
implements dynamic binding to the type. Oberon and Oberon-2 cover most terms of object-oriented languages
IMPORT Ob2DGraphs3. Gadgets; TYPE UserProc*=PRoCEDURE;
but are smaller than most of the other object-oriented
VU
languages , therefore they are suited to be used in teaching object-oriented programming techniques. The most important features that make Oberon and Oberon-2 object-oriented programming languages are
brie8y listed here. • A bstroet data type An abstract data type is a user-defined type which eJlcap~ulates
private data together with a set of op-
erations t hat can be used to manipulate the data. Data abstraction has three important benefits: information hiding, simplification of documentation
and freedom of implementation. • Type extension From nny e.xisting record type, new types can be
derived that have addit,ional fields but remain compatible with the existing type.
• Type-bound procedures and dynamic binding In Oberon, dynamic binding i. achieved through procedure variables that appear as fields in a record . In Oberon-2 , procedures can be connected to a data type explicitly, such procedures are caBed type-
bound procedures. Message records (handlers) with broadcasting techniques are also used. Oberon is available in several versions. There is a basic
Oberon system call Oberon V4 and an object-oriented
DEFINITION Si.uBase3;
Dynamic*:PRDCEDUREi (* contains differential equations .) Model. : PROCEDURE; (* defining the state variables .) XYframe*:Ob2DGraphs3.XYFramei (. graphica window.) graph. :Ob2DGraphs3.Graph; (. graphiCS .) PROCEDURE DecIXV* (VAR x,scale:REAL: nUle: ARRAY OF CKAR); (. declare measurable variables for plotting . ) PROCEDURE DeclSV.(VAR x,xDot ,xO: REAL); (. declare state variables .) (* running the simulation .) PROCEDURE Run'" i PROCEDURE RunContinue.; PROCEDURE SetlntegrationTlm •• (t:REAL);(", step length .) PROCEDURE SetSillUlationPeriod*(pd : REAL) ; PROCEDURE SetUserProcedure.(up:UaerProc) ;
(* interrupt procedure *)
(. graphics *) PROCEIKniE ClearGraph*j PROCEDURE ClearPlotFrame*; PROCEDURE DravCurve*; PROCEDURE DrawGraph*i PROCEDURE DrawPoint.j PROCEDURE DpenPlotrra.e.; END SiD.u8ase3.
DecLSV and DeclMV are the procedures (or defining state variables and monitoring variables for screen output l respectively. Dynamic is used to describe model's
dynamics as state equations alld Model to define the model quantities and the display. Examples of using this
951
simulator are shown in section 3.2. Ob2DGraphs3 is a module for the graphical representation of signals in linear and logarithmic scales. In this module a new gadget called XYFrame has been developed, which extends Gadgets.l.rame. It is again presented by the definition module: DEFINITION Ob2DGraphs3; IMPORT Gadgets,Objects,Display,Texts,Oberon,Vievers,Fontsj TYPE (* the basic types are of POINTER type *) AxisType*-RECORD range*: Range; scale*: SHORTINTj label*! LabelString:
END; Curve*-POINTER TO CurveDesc; CurveDesc*-RECORD color* : SHORTINT; symboh: CHAR; l~gend*: ARRAY 32 OF CHAR:
(* curves *)
END;
Graph*-POINTER TO GraphDesc; (* graphS *) GraphDesc*;RECORD grid*: BOOLEiN; axis*: ARRAY 2 OFAxisTypsj font*: ARRAY 32 OF CHAR; END;
XYFrame*-POINTER TO XYFrameDesc; (* frames *) XYFrameDesc*-RECORD(Gadgets.FrameDesc) graph*: Graph: END·
RestoreProc*=PROCEDURE(f: XYFrame); (* restore frame procedure *) UpdateProc *-PROCEDURE(f: XYFrame; ... ); (* update frame procedure *) (* Procedures for curves *) PROCEDURE DefineCurve*(f: XYFrame; VAR c:Curve: ... ); PROCEDURE RedefineCurve*(c: Curve; .. ); PROCEDURE Plot*(f: XYFrame: c: Curve: navX, nevY:REAL); PROCEDURE PlotCurve*(f: XYFrame; c: Curve; ... ); PROCEDURE PlotSym*(f: XYFramej ch: CHAR; X,Y:INTEGER); PROCEDURE DrawLegend*(f: XYFramei c:Curvej ... )i PROCEDURE ClearCurve*(c: Curve); PROCEDURE RemoveCurve*(f: XYFramej c: Curve);
SimuBase3 is about 10 pages of code, Ob2DGraphs3 about 20. This demonstrates the power of the basic idea of extensible systems. The simulation code for the hydroturbine system will be briefly discussed in the next section.
3. MODELLING AND SIMULATION OF SMALL HYDROPOWER STATIONS A model for the small hydropower station, which was obtained in (Glattfelder et al., 1994) is shown in Fig.!. The model equations are not repeated here, as they have been discussed in (Bierther, 1995; GIattfelder et al., 1994; Ramseier, 1994). The aim of this part is to illustrate how Oberon facilitates object-oriented programming and simulation by making direct use of the gadgets interface. The intention is not to develop a full-fiedged power station model, but to illustrate general ideas with concrete examples.
3.1 Modelling and graphical user interfaces An easy to use graphical user interface is vital for the kind of training and instruction envisaged by our project. Figure 2 shows the block diagram of a small hydropower plant with rotor speed control. It is generated with Oberon system 3 and Gadgets and serves as ODe of the main graphical user interfaces. The block diagram allows easy access to the parts of the simulation. The blocks can be opened, edited and closed again, ready for execution. During training, the code is not changed, all blocks have been carefully parametrized (see Fig. 3) to allow all interesting investigations without any reprogramming.
(* Procedures for frames *) PROCEDURE NewXYFrame*; PROCEDURE OpenFrame*(VAR F: XYFramej ... ); PROCEDURE SetFrameAttribute*j PROCEDURE SetRestoreProc*(F: XYFramej rp: RestoreProc): PROCEDURE SetUpdateProc*(F: XYFramej up: UpdateProc); PROCEDURE ResetFrame*(F: XYFrame); PROCEDURE RestoreFrame*(F: XYFrame)j PROCEDURE ClearFrame*(F: XYFrame); PROCEDURE RemoveFrame*(VAR F: XYFrame);
END Ob2DGraphs3.
Fig. 2. Block diagram of a small hydro power station with control system
952
A Hydrodectrk PoWIH' Statio.
very simplified
r - - - -----.-
L. grid SY31em
power house pDS_ conIl_ :posili oo oonlroJ
iIpccd ooatr. : speed conlrol
powu cont.-. : ~ control
(J
local consumer y: pmi~un
type of controlk:': J>t'P1
"sr.: tel po\III. or JPted (50Hz.)
~: =v~~~ C':.'7Jfrequ.e.cy conlrol
n: adual value of speed G: ~)'nc:h.1OftOWl GeneraLOf
Fig. 1. Schematic diagram of a small hydropower station with control system with *) so that they can be changed in client module WKWDiag or WKWDispl. The module structure is shown in Fig. 4.
,
I Strecke, Regler, RegStre, Vcrbund, Insel, Parallel "l I WKWDispl I
I Fig, 3, Parameterization of the subsystem Leitung (penstock) and Servomotor
SimuBase3
•
I
•
I
•I
WKWDiag
f
IOb2DGraphs31 ,
3,2 Using the simulator
I Oberon System 3 with Gad~ets
In SimuBase3 Model and Dynamic are defined as exported procedure variables. They must be assigned to
I
I
WKW
I
user-defined procedures in client modules.
Fig, 4, Module structure
In our application the behaviour of the composite mod· els is described with first-order differential equations and algebraic equations. Each model component is defined in one procedure. All of these procedures are put in the
In client modules the components are put together to build the simulation models. For example, a hydropower plant with PI-Controller and loading on a very large grid (see Fig, 2) is defined in module Verbund , The defini· tion module Verbund and procedures Stausee (upstream reservoir) as well as Druckleitung (pen.tock) from Mod· ule WKW look like this:
h..., module WKW. In module \VK\V model parameters and monitora.blc variables are defined as exported glohal variables (marked
953
MODULE Verbund; IMPORT Si.uSase3.WKW.WKWDispl,WKWDiag; PROCEDURE Dynamic; (. the 8ta~es are globally defined and CaD be accessed by all procedures -) BEGIN WK\I . St&usee; ~V . Druckleitung;
WKV.Regler; WKlI.Servo; WKW . Rotor; Wl
PROCEDURE Model; BEGIN xO: - 0.0; scale:= 1.0; SimuBase3.DeclSV(wRotor,wRotorDot.xO); .. . SimuBase3.0eclHV(vRotor,scale,"vRotor"); .. . END Model; PROCEDURE Run-:
BEGIN SimuBaae3.Hodel :- Hodel; SimuBase3.Dynamic :- Dyna.ic: SimuBase3 . Run;
the corresponding procedures exported by the module WKW.Mod, different system configurations, e.g. Strecke, Regler, RegStre and Verbund (see. Fig. 4) can be simulated with the simulator. The simulator is controlled interactively by the user. Figure 5 shows the typical simulation environment. The user first opens the block diagram and parameterizes the model as shown in Fig. 3, sets or changes the integration step and simulation period in the "Simulation Param eter' ~ palld~ selects the monitorable variables to be plotted in the "Monitor Variable" panel, defines the range of the axes and colour of the XYFrame in the "Graph Parameter" panel, and finally launches the simulation by pushing the button labelled "Run". The monitorable vari~bles are then plotted on-line in the XYFrame. During the simulation run, the user can change the controller parameters interactively or handle events like switching in/off the genera,. tor or increasing/decreasing the 10.0. He can also terminate the simulation at any time by activating the button labelled "Stop". Once the simulation period is attained, the user can continue the simulation by pushing the button labeUed "Continue".
END Run;
END Verbund.
MODULE WKW;
PROCEDURE Stauaee.; BEGIN
qWeg :- kSe •• (bS.e-hSeeLim); IF qWeg < 0.0 THEN qWeg := 0.0: END: IF bSee < 0.0 THEN hSeeDot :- 0.0; ELSE bSeeDot: - (qZu-qWeg-wLeitung)!Tsee; END ; END Stausee;
PROCEDURE Druckleitung.. i CONST delta - 0.05; b - 0 . 1; BEGIN
vLeitungDot:-1 .0!Tv-ChSee-b+(1-h)-pLeitung -delta _ABSCwLeitung). vLeitung); IF pLeltung
END; END Druckleitung;
The simulations may easily be .oapted to many operating conditions with different configurations (pelton or crossflow turbine, working in an isolated grid as a single unit or one of two interconnected suppliers or on an infinite bus) and with different controllers and control strategies (frequency, load or forebay level control). For each typical configuration a separate module has been built, mainly for didactic reasons. When using the simulator the trainees can change the system parameters and substructures, but only in ways that have been foreseen and prepared, whereas the trainers can change the source code of the programs and change the graphical representation to adapt them to new needs. Therefore the free availability of the source code is obviously a necessity. The package for modelling and simul"tion of small hydropower stations with control systems currently runs on PC and Macintosh.
END WK\l.
4. CONCLUSIONS 3.3 The interactive simulation environment The basic design of the interactive simulation environment is composed of graphical user interfaces as described in 3.1 and the simulation of the concrete system as described in 3.2.
With the model components stored in WKW.Lib and
Simulators for small hydro power stations can easily be realised by a new simulator for continuous systems developed in Oberon. These simulations show the hnpor~ tant aspects of dynamic behaviour and can be made generally available for operator training.
It is also illustrated how Oberon facilitates object-oriented programming and simulation with a. realistic and COll-
954
Fig. 5. Simulation environment and an example (parallel operation of the plant on an infinite bus..., synchronisation
and stepwise loading; simulated model: Verbund) crete example. The simulation example described in section 3 shows
that Oberon makes developing and extending simulators and graphical user interfaces very easy. Moreover, simulawrs developed with Oberon are portable.
5. REFERENCES
Bierther, J. (1995). Simulation einer Wasserkraftanlage in Oberon (JI). Term project. ETH Zurich. Glattfelder, A. H., X. Qiu, J. Ramseier, W. Schaufelberger and R. Widmer (1994). Modelling and simulation of small hydro power stations. In: Proceedings of CISS'94. Zurich. pp. 206-210. Gutknecht, J. (1994). Oberon System 3 - A Realm of Persistent Objects. Report. ETH Zurich. Marais, J. L. (1995). The Gadgets Guide (Release 2.0). Report. ETH Zurich.
Mossenb6ck, H. (1993), Objektorientierte Programmierung in Oberon-E. Springer-Verlag, Berlin, Qiu, X. and W, Schaufelberger (1994). Computer aided control system design with oberon. In: Proceedings of CACSD'g4, Tucson, pp. 271-276. Ramseier, J. (1994). Simulation einer Wasserkraftanlage in Oberon (J). Diploma project, ETH Zurich, Reiser, M. (1991). The Oberon System - User Guide and Programmerjs Manual. Addison-Wesley. New York. Reiser, M, and N. Wirth (1992), Programming in Oberon - Steps Beyond Pascal and Modula, ACM Press, New York, Veitrop, J. A. (1992), Hydropower: Needs, challenges and opportunities. In: Proceedings of Hydropower'g2. Lillehammer. pp. 3-10, Wirth, N, and J, Gutknecht (1992), PROJECT OBERON - The Design of an Operating System and Compiler. Addison-Wesley. New York.
955