application of activated sludge models in traditionally operated...

Water Qual. Res. J. Canada, 2004 • Volume 39, No. 3, 294–302Copyright © 2004, CAWQ

294

Application of Activated Sludge Models in Traditionally Operated Treatment Plants—

A Software Environment Overview

Mohamed Tarek Sorour and Laila M.F. Bahgat*

Sanitary Engineering Department, Faculty of Engineering, Alexandria University, 21544 Alexandria, Egypt

Activated sludge simulation modelling is considered an accepted tool in engineering practice. However, due to the complex-ity involved, these models are only extensively used within a limited scientific community. There is a true need to increasethe use of these models among average plant operators to make them better understand the interactions of various factors ofthe process. A user-friendly software environment that enables an ordinary user to access and use these models to simulate asystem without the need for either a complete understanding of underlying models or any special programming skills willhelp promote model applications.

This paper defines the broad architecture of such an environment and identifies other applications that should be inte-grated into the simulator such as expert systems and database systems. It also discusses the steps necessary to develop a reli-able site-independent activated sludge simulator. Finally, the paper points out that to introduce mathematical model simula-tions to traditionally operated treatment plants, a how-to protocol is needed to adjust routine operating data for model use.

Key words: activated sludge models, expert systems, simulation, software environment, traditionally operated treatmentplants

Introduction

Currently, the activated sludge process is the mostwidely used biological process for secondary wastewatertreatment for effluent quality, worldwide. Many modelswere proposed to provide a description of the complexbiological reactions that take place within the process. In1987 the International Water Association (IWA, for-merly IAWQ and IWPRC) Task Group for Mathemati-cal Modeling for Design and Operation of BiologicalWastewater Treatment introduced the Activated SludgeModel No.1 (ASM1) to unite many of these previous sci-entific efforts in what was considered then as the state-of-the-art model (Henze et al. 1987). ASM1 allows sim-ulation of the behaviour of nitrifying and denitrifyingactivated sludge systems, which primarily treat domesticwastewater. ASM1 immediately gained wide acceptanceand became a major reference for further research work.Since then, ASM1 is in wide use (primarily for nitrogencontrol), and many activated sludge plants are nowmodified to allow for phosphorus removal as well. Thiscalled for the task group to present model 2 (ASM2) in1995 and its minor extension (ASM2d) in 1999 to pro-vide an understanding of the processes involved in bio-logical phosphorus removal (Henze et al. 1995, 1999).To accommodate for these mechanisms, more com-pounds and processes were added leading to a more

complex structure compared to ASM1. The task grouprealized that the level of understanding of phosphorusremoval processes was not very reliable and as suchhoped that ASM2 would encourage scientific debateleading to further developments towards a more reliablemodel (Henze et al. 1995). Finally, in 1999 the taskgroup proposed model ASM3 to correct some of theapparent limitations of ASM1, returning to the structureof the less complex model as phosphorus removal wasnot considered (Gujer et al. 1999). All this enhanced theuse of activated sludge models within the scientific com-munity and among consulting engineers for a variety ofpurposes ranging from research to treatment plantdesign, operation, control and troubleshooting. Manysoftware packages built upon these models, particularlyASM1, are available today. However, most of these soft-ware tools were developed for research or for practicalapplications in consulting companies and are not wellsuited for application by plant operators or for teachingpurposes (Morgenroth et al. 2002). This paper aims toraise attention to this important aspect and to identifythe means to achieve wide application of complex mod-els among plant operators.

Define Objective

Operational practice shows that plant operators dependmostly on accumulated experience in monitoring acti-vated sludge plants and coping with emergency situa-* Corresponding author; [email protected]

tions. Skillful operators tend to develop an understand-ing of how to monitor their plants by taking advantageof observations related to colour, foam and odour (Gall1989). As their experiences grow they get to know whenthe plant is in actual need of corrective measures andwhen it is best to let what seems to be a problematic sit-uation pass with no interference (Water EnvironmentFederation 1996). Their performance could be improvedif they were equipped with computer systems such asprocess simulators and expert systems that provide rapidaccess to information about the plant state. A processsimulator can predict how the actual system reacts undervarious conditions, thus providing operators with insightinto the internal workings of the physical system andhelp them avoid many unfavourable situations beforeactually turning into operational problems.

Conversely, expert systems condense all the knowl-edge and experience about the treatment of a processinto an easy-to-use means that provides immediateadvice whenever human experience is a must. More-over, if necessary, all types of calculation procedures,algorithms of several processes, etc., can be embeddedwithin the knowledge stored in the expert system. Thiscan help operational staff immediately define correctset points in the plant under varying conditions insteadof getting involved in lengthy calculations. Mostimportantly, when situations arise that the operatorshave not experienced, expert systems will aid them inrecognizing and assessing problems as well as findingadequate remedies (Ladiges et al. 1994). Due to theirinternal architecture, expert systems are a valuable toolfor training purposes, especially if the user’s informa-tion is constantly tested against the system’s advice fora variety of practical cases. Whenever these systems areinterlinked with other information sources they becomemore powerful. For example if an expert system islinked to a database system in a way that it lets theexpert system directly access data records, a sort ofintelligent database will be developed. This enables theexpert system to arrive at a decision based on the latestavailable data and makes the most of the plant’s rou-tine data records. A similar approach was adopted dur-ing the development of an expert system called theActivated Sludge Expert (ASExpert) dedicated for inex-perienced activated sludge plant operators (Bahgat2000). A direct interface was established between theexpert system and the database and as a future step itwas recommended to integrate a simulation modellingtool to ASExpert to test the validity of the expert sys-tem’s advice before actual execution (Bahgat 2000).This paper briefly describes the ongoing work todevelop a complete software environment that incorpo-rates ASExpert with a process simulator as one infor-mation systems toolbox. In order to correctly definethe simulator’s intended role, the paper starts by pre-senting a brief description of a coupled activated

sludge/settler system and how the equations comprisingthis system are formulated.

ASM1 as a Typical Example

of Activated Sludge Models

Mathematical Formulation of Model ASM1 Equations via Mass Balance

ASM1 uses 13 model components and eight transforma-tion equations to describe the reactions that take partinside the aeration tank leading to carbon and nitrogenremoval (Henze et al. 1987).

To cope with the complexities involved, Peterson’smatrix format is adopted for model presentation wheremodel components and processes are characterized asmatrix columns (given the index i) and rows (given theindex j), respectively. Process rates (ρj) are formulatedmathematically and listed down the right-hand side of thematrix in line with the respective process. Stoichiometriccoefficients (vij) for the conversion from one component toanother are expressed using consistent units or CODequivalents along each process row. The overall reactionrate of each component, ri, is obtained by moving downeach column and multiplying the stoichiometric coefficient,vij, with the respective process rate, ρj, then summing up:

ri = Σj vij (1)

To obtain the complete set of equations describingthe system, these rates need to be complemented by massbalance terms according to the principal of conservationof mass and energy:

Rate of Accumulation = Rate of Input – Rate ofOutput + Rate of Production by Reaction

Assuming that the reactor is fully mixed with a con-stant volume, V, this results in a set of ordinary differen-tial equations (ODEs) of the general formula:

dCi/dt = Q/V(Ci, in – Ci) + ri (2)

where Ci is the concentration of component, i, insidethe reactor and Ci, in is its concentration in the influentto the reactor or zone. Q represents the flow through thecontinuously stirred tank reactor where inflow and out-flow rates are equal. Following this basis, if the reactoris divided into separate anoxic and aerobic zones, eachzone should be treated as a separate unit with its owncharacteristics such as volume, flows and process con-stants (Samuelsson 1998).

As the reaction rates are mostly growth rates basedon non-linear Monod-type expressions, the set of ODEscomprising the model will be non-linear as well and can-not be solved analytically. Therefore, after determiningappropriate initial conditions of model components,numerical integration techniques based on Euler and theclassical fourth-order Runge-Kutta methods are usuallyadopted for model solution (Billing et al. 1988).

Software Environment Overview 295

296 Sorour and Bahgat

Modelling of the Settlement Process Using One-Dimensional Multi-Layer Models

To obtain realistic results from ASM1, it has to be usedin combination with models capable of efficientlydescribing the settlement process (Henze et al. 1987).For the purposes of plant operation and operator train-ing, the settlement process can be fairly representedusing one-dimensional multi-layer models that modeldynamics according to the solids flux theory in the verti-cal direction only (Ekama et al. 1997). According toFig. 1 the basic idea behind one-dimensional multi-layermodels is to divide the settler into a number of com-pletely mixed equidistant layers (1:n) and formulatemass balances for each layer to keep track of total sus-pended solids within each layer.

The layers of the settler are characterized by differentproperties (determined by their position respective to feedlayer) with mass exchange (hydraulic and sedimentationflux) between the layers. The feed layer receives thewastewater stream from the biological part of a waste-water treatment plant. Above the feed layer (clarificationzone) there is an upward hydraulic flow caused by waste-

water flow and below the feed layer (thickening zone)there is a downward hydraulic flow caused by the returnand waste sludge flows at the bottom of the settler.

In all layers a sedimentation flux occurs due to gravitythat is calculated by the settling velocity function multi-plied by the corresponding layer suspended solids concen-tration. The double exponential settling velocity functionproposed by Takacs et al. (1991) (equation 3) is usuallyadopted because it is applicable to hindered and flocculentsettling conditions (thickening and clarification zones).

vsj = max(0,min{v’0,v0[e-rh (Xj – Xmin) - e-rp (Xj – Xmin)]}) (3)

where vsj is the settling velocity in layer j, Xj is sus-pended solids concentration in layer j, Xmin = fnsXf is theminimum attainable suspended solids concentration, fns isthe non-settleable fraction and Xf is the mixed liquor sus-pended solids concentration entering the settler. v’0 andv0 are the maximum practical and theoretical settlingvelocities, respectively, rh and rp are parameters charac-teristic of the hindered settling zone and the settlingbehaviour at low solids concentrations, respectively.

With the help of Fig. 1, the set of derivative equa-tions comprising the settler model can now be obtained

Fig. 1. The basic principal of the traditional one-dimensional layer settler model with equidistantlayers and constant cross-sectional area after Takacs et al. (1991).


by performing a mass balance for each layer. For exam-ple, the changes in solids concentration within layer 2 isexpressed as:

dX2/dt = (Jup,3 - Jup,2 + Js,1 - Js,2)/height of layer 2 (4)

The feed layer, top layer through which effluentgoes and bottom layer where recycling to the aerationtank takes place must be explicitly coded by a separateequation for each layer (Ekama et al. 1997). The middlelayers, whether in the clarification or thickening zones,can be easily represented mathematically by one equa-tion for each group.

Reactor/Settler Coupling

To represent both the reactor and settler as one inte-grated system, consistent units must be used within boththe biological and settler models.

ASM1 particulate components are converted fromthe COD unit into one variable (Xf) that describes thetotal suspended solids in the feed to the settler with theunit (mg SS/L) used within gravity settling models(Jeppsson 1996).

Literature documents several conversion relation-ships that can be used to compute Xf including the onepresented here proposed by Henze et al. (1995):

Xf = 0.75*(XS + XI + XP) + 0.9(XBH + XBA) (5)

where XS, XI, XP, XBH and XBA are ASM1biodegradable, inert, cell debris, heterotrophic biomassand autotrophic biomass particulate components,respectively.

ASM1 soluble components need no conversionregardless of the different units used (mg COD/L or mgN/L) as soluble material only follow bulk flows and itmay be assumed that there are no biological reactionstaking place in the settler.

The integrated set of reactor/settler derivative equa-tions is then directed to the selected numerical integrationsolver to be solved simultaneously typical to the proce-dure depicted in Fig. 2. At the beginning of each simula-tion iteration, particulate fractions in recycle flow must

be estimated back from the suspended solids concentra-tion of the settler’s bottom layer (Xu) using the ratios ofthese fractions to the composite term Xf at the feed to thesettler (zone 3 in Fig. 2) typical to the following relation:

Xir = Xi3/Xf*Xu (6)

and all particulates in reactor zone 3 must belumped into one suspended solids concentration whenentering the settler.

After this quick review of the nature of the modelsto be simulated, the complete architecture of the pro-posed environment can now be presented.

Architecture of the Proposed

Software Environment

According to Fig. 3 a well-designed graphical user inter-face (GUI) is the means of user interaction with theseessential components:

1. The readily available component or system ASExpert.a. The expert system tool.b. The database tool (record manipulation, report

generation and graph representation subsystems).2. The proposed simulation-modelling program made

up mainly of a model library, numerical integrationsolver and a graphical output facility.

ASExpert’s internal architecture is composed of sev-eral elements. Typical to any other expert system theknowledge base and inference engine are the system’smain building blocks. First, the knowledge base is the sys-tem’s repository of domain knowledge coded in the formof rules. Rules take the form of “if-then” associations, i.e.,two-part conditional statements that represent heuristicsor rules of thumb. The antecedent expresses a situation ora premise while the consequent states a particular actionor conclusion that applies if the situation or premise istrue. Second, the inference engine is the system’s controlmechanism that makes inferences and decides which rulesare satisfied by facts, prioritizes the satisfied rules on a listcalled the agenda and then executes the rule with the high-est priority. The working memory works in harmony with

Fig. 2. A schematic description to relate model particulate fractions in the last zone of the reactor with Xf andrecycle composition with Xu.


the inference engine to model human short-term memory.It contains the facts of the current situation whetherentered through user input or inferred as a result of rulesfiring (execution). Finally, the inference engine can also beprogrammed to provide the explanations behind the sys-tem’s reasoning which is usually achieved through theexplanation facility block (Giarratano et al. 1998). Otherexternal programs such as the database tool, rule editor,etc., provide additional support to the main program. Asstated earlier, there is an established interface between theexpert system and database system (Bahgat 2000).

Main building blocks of the intended simulator. Toadequately simulate an activated sludge system, a simu-lation tool must mainly account for a model library,numerical solution procedures and a graphical represen-tation output facility.

The model library. A straightforward simulator thatcan be easily implemented by inexperienced users shouldadopt a closed model structure. Accordingly, the simulatormodel library provides the user with a set of predefinedmodels that can be used to implement a specific activatedsludge system. The user has no choice but to select a prede-fined model or coupled models (reactor/settler model) from

within the set of available models. Model parameters mayalso be predefined or the user may be allowed to introducehis values (within the range of accepted values).

Simulated configuration setup facility. This compo-nent is not an essential part of the simulator’s architec-ture because a basic simulator will usually adopt a pre-defined process scheme regarding the type and numberof reactors, connection between different units, etc., andthe user has no freedom to define his own specificationsother than manipulating a few variables.

Numerical solvers. As stated earlier the implementedmodels involve non-linear processes and mass balanceequations that are represented mathematically as a set ofcomplex ODEs that can only be solved by numericalintegration methods. Numerical solvers representadvanced software codes based on these methods.

Graphical result output facility. To promote useracceptance in today’s world of sophisticated applications,graphical representation of results is very much stressed.

The Simulator’s Development Procedure

The development of an activated sludge system simula-tor is not a trivial task due to the complexity of the mod-

Fig. 3. The architecture of the proposed software environment.

els used. If it is required to simulate a specific plant theplant’s site-specific control procedures must be includedin the simulation. Also, computer simulations must bevalidated with experimental or full-scale data. This callsfor a well-defined framework or methodology to identifythe simulation model(s), plant layout, evaluation andtest procedures and all other elements necessary to facili-tate introducing the developed simulator for use in realplants as a future step. Recent technical literaturestrongly reveals a trend towards similar standardizedprocedures. Although the reported protocols were devel-oped to serve different aims, all were triggered by onecommon motive: to provide a how-to practical protocolthat benefits from accumulated experiences, unifiesinconsistently available knowledge and most importantlyto set some form of quality control. Thus the COST sim-ulation benchmark was implemented as a test vehicle foractivated sludge control strategies (Spanjers et al. 1998;Copp 2000; Rosen 2001). This benchmark is a method-ology not only comprised from a simulation model butalso of a complete protocol on how to run tests and doc-ument results. Hulsbeek et al. (2002) reported a protocolset to aid in the introduction and acceptance of dynamicmodels in full-scale plants in the Netherlands. Similarly,in reporting experiences with computer simulation attwo large wastewater treatment plants in Poland,Makinia et al. (2002) stressed the need for a methodol-ogy to adjust routine operating data for modelling pur-poses. The simulator’s main requirements were identifiedand the plan for development was set after a carefulstudy of these research experiences.

Identify the Simulator’s Main Requirements

Figure 3 introduced the simulator’s main building blocksthat define basic functions only. However, to improveperformance, additional features are needed. The follow-ing points sum up the simulator’s main requirements:

1. To provide access to model parameters, physical dataof simulated scheme (volumes, flows, etc.) and statethe variables’ initial conditions in each case. Thisenables users to conduct what-if analysis by lettingthem to view and introduce changes to the variablesthey are authorized to manipulate such as recycle andrecirculation flows, and hydraulic and organic flows,that may be adjusted to represent peak values, etc.

2. To use real dynamic data as input in order to producerealistic simulation results and to provide a facility toprint these results or save them as computer files.

3. As a future requirement, practical real-world appli-cation of the simulator stresses the need for a morecustomized GUI that allows the user to represent anactivated sludge plant of his own specifications as aschematic diagram on the monitor’s screen as well asto interactively manipulate this diagram. Such an

interface should provide the user—through simplemouse clicks—with the versatility to customize theplant’s modes of operation and control to some per-missible extent according to his desire (e.g., betweenpre-denitrification and post-denitrification) and toset simulation start-up conditions, number of anoxicand aerobic reactors, etc. Accordingly, the plant’sschematic diagram should be immediately redrawnon the screen to reflect these modifications (highlightactive pumps, dim inactive pumps, show air bubblesin aerobic zones and remove air bubbles from anoxicones, etc.). Eventually, simulations should start uponuser request when the user is completely satisfiedwith his selections. However the user will still berestricted to use a set of predefined models.

Outline of a Four-Stage Plan for the Development of the Simulator

The development procedure is organized into four well-defined stages that follow the three development stagesof ASExpert (Fig. 4):

• Stage 1: setting up a development framework. • Stage 2: implementation of the system’s models and

verification of initial results.• Stage 3: implementing a GUI for the simulator and

linking it with the numerical solver.• Stage 4: future simulator improvements and possi-

bility of embedding it within a multi-system infor-mation toolbox.

The following section highlights some of the impor-tant aspects related to each stage.

Stage 1. The overall simulation model (process models tobe implemented, influent model, parameter values and ini-tial values) and verification procedure were set in accor-dance with the COST simulation benchmark (Copp 2000).

• Implemented models are ASM1 and the double expo-nential settling velocity model of Takacs et al. (1991).

• Parameter values are chosen as the default values ofthese models’ kinetic and stoichiometric parametersat a temperature of 20ºC.

• Plant layout is the COST simulation benchmarkdefault plant layout, which is a commonly used pre-denitrification configuration, comprised of twoanoxic reactors followed by three aerobic reactorsand a sedimentation unit.

• Influent data files. Three files were developed withinthe COST simulation protocol to represent normaldry weather inflow, storm and rain conditions. Thesefiles contain data (model fractions ready for use inthe simulations) taken at 15-min intervals for a 14-day period in a way that represents a fair descriptionof a true influent profile (regarding expected diurnalvariations in influent flow and COD as well weekly



data patterns) of a plant of the chosen size (Copp2000). These files are used to verify the results of thedeveloped simulator and can be downloaded fromthe COST benchmark Web site (Copp 2000).

• Simulator verification procedure. To ensure a con-sistent starting point and to eliminate the influenceof starting conditions on the generated dynamic out-put, the COST simulation benchmark describes atwo-step procedure that involves simulation tosteady state followed by dynamic simulations usingthe three defined influent files. According to Copp(2000) initial states for dynamic simulations can beobtained by simulating the set of ODEs under aninput of constant flow and composition—providedin the benchmark—for a period of 100 days. Fol-lowing simulation to steady state, the generated out-put data must be compared to the standardized out-put that is included in the benchmark description.Only when similar steady state results are attainedshould dynamic simulations be initiated using thethree dynamic input files. For a complete descriptionof the verification procedure see Copp (2000).

Stage 2. The tasks dedicated to this stage include theselection of the development languages or software toolsto be used for implementation regarding the simulator’srequirements and the capabilities of available tools. Thefollowing section discusses some of the importantaspects related to this stage.

The need for built-in stiff numerical integrationsolvers. The models of the present system take the form ofnon-linear ODEs and as such to cut down developmenttime considerably, there is a demand for readily availablenumerical integration solvers that could be directly used

as built-in routines or functions. From this respectMATrix LABoratory (MATLAB) by Mathworks is a gen-eral, high-performance technical computing language thatprovides easy access to a whole suite of ODE solverscapable of efficiently solving a variety of differential equa-tions systems including initial value problems typical tothe present activated sludge system. Some of these solversare also based on algorithms specifically dedicated to dealwith stiff systems (Hanselman et al. 2001) similar to thepresent system where the time constants for the differentprocesses of the simulated model vary significantly andrequire special integration algorithms to handle. MAT-LAB is also equipped with an integrated simulation tool-box called Simulink capable of providing real-time graphi-cal representation of simulation results. Finally, it is worthmentioning that MATLAB may be considered the easiestand most straightforward method for implementing com-plex mathematical models even for the inexperienced pro-grammer. All this makes MATLAB a highly suitable can-didate for implementation.

The need for a GUI interface. Requirements indi-cate that the simulator should use a user-friendly inter-face capable of interactively taking in user input andproviding a graphical result output. Then, as a futurerequirement, capable of providing some means of plantlayout definition. Although MATLAB can be used forGUI implementation, the real-time update of a complexinterface would be too time-consuming in such a case.Thus, a general-purpose programming language such asVC++ or Java will be more suited to fulfill theserequirements. This raises another issue, which is thenecessity for establishing some means of connectionbetween MATLAB, that acts as the background engine,and the interface.

Fig. 4. A stepped procedure for the environment’s development.

Reasons that favour choosing Java for the implemen-tation of the interface. Java contains a rich set of GUIcomponents that can handle most of the fundamentalrequirements of programs. This makes it easier and fasterto use (Liang 2000; Martin 2001). Java is a multithread-ing language where multiple tasks can be run simultane-ously in one program, thus satisfying the need for aresponsive user interface. Despite being an interpretedlanguage Java has a relatively high performance speedsufficient to handle most real-time interactive applica-tions (Samuelsson 1998; Martin 2001). In addition thereis currently an enormous worldwide interest in Java andthere are a lot of powerful Java integrated developmentenvironments (IDEs) that speed up coding, debuggingand facilitate the development process to a great extentby freeing the developer from time-consuming tasks,enabling him to focus on providing the real solutions.

Establishing an interface between Java and MAT-LAB. Software public domain currently provides adynamic link library (DLL) called JMatLink.dll that iscapable of integrating Java with MATLAB withoutmuch programming effort. Although this DLL is still notsupported by Mathworks, it may be tried as a quick steptowards fulfilling the objective.

Results of initial model implementation. The reac-tor/settler (ASM1, Takacs et al. [1991] double exponen-tial velocity) coupled models were coded using MAT-LAB. The two-step simulation-verification procedurewas conducted. Obtained results were evaluated in lightof the provided standardized output. Initial testingshows that MATLAB numerical integration solvers arecapable of satisfying requirements.

Stage 3. After verification of initial model implementa-tions, effort was directed towards fulfilling the simula-tor’s GUI requirements. A Java GUI was hastily devel-oped and used to build up the simulated system typicalto user desire. Then using the public domain DLL file(JmatLink.dll), user input was directed to the MATLABenvironment to do the necessary computations and savethe output as a text file. Initial testing of the developedapplication gives a promising indication that this tech-nique is capable of satisfying requirements, which shouldencourage the development of a more functional GUI inthe future.

Stage 4 (future directions). Tasks of stage 4 are notcompletely fulfilled yet. Attempts are dedicated to encour-age more interactive manipulation of the simulator’s GUIand to modify current database systems to incorporatedata necessary to start simulations (influent files) and saveresults for future use. Effort will focus on selecting ade-quate calculation procedures from literature to convertroutine plant parameters, e.g., COD and TSS into modelfractions. These procedures can then be introduced to thesystem to directly do the required data adjustment.

Finally, attempts will be directed towards integrat-ing the developed simulator with ASExpert in one envi-ronment. It is not apparent at present whether a directinterface can be established between both systems andwhether this capability would be of any specific advan-tage. However, under all conditions the environmentmay be regarded as a multi-system information toolboxthat provides access to several tools capable of satisfyingdifferent needs.

Effective Application of Model Simulations in Traditional Plants

User-friendly software applications like the proposedenvironment might help the utilization of model simula-tions in traditional plants. Nevertheless, the availabilityof easy-to-use software is not enough. Introducing modelsimulations into an existing plant is a lengthy and diffi-cult task. First the plant must be carefully examined andcritically evaluated to check whether its process configu-ration has been altered by operational staff and to whatextent. Errors in flows and set points are very critical tosimulations. Next, a systematic procedure must be devel-oped for influent characterization and model calibration.Hulsbeek et al. (2002) reported that such a proceduremust follow a standard methodology based on practicalexperience not only to minimize time and cost effortsbut to ensure using reliable and feasible methods. Thus,measurement procedures should be determined accord-ing to the sensitivity of different concentrations towardsmodel parameters because literature reports that manymodel parameters in full-scale systems are not sensitive.

Under traditional operation, the situation is evenmore difficult because the number of measured parame-ters is limited. Usually only a few routine analyses ofconventional parameters such as BOD5 and TSS are per-formed and these are not directly applicable to model-ling. Consequently, even if only a few coefficients needadjustment during calibration, the specialized studiesnecessary to estimate these coefficients such as batchtests or concentration profiles are usually not conducted.Therefore, the adopted methodology must be extendedto include a how-to protocol that defines the methodsnecessary to make conventional data capable of satisfy-ing modelling purposes (Makinia et al. 2002).

Conclusions

Simulation models of activated sludge plants are still sel-dom used by plant operators. The limited use could berelated to the level of complexity of the simulation soft-ware and mainly to the unavailability of ready-to-use data.

In cases where it proves to be economically infeasi-ble to upgrade existing plants to automatic control facili-ties the only possible alternative to improve plant opera-tion is to leverage the skills of operators. This can be


achieved through effective computer systems that pro-vide rapid access to information about the plant’s statein a visual, easy to grasp, graphical form. Appropriateinformation sources are primarily simulators and expertsystems. Moreover if these powerful systems are inte-grated in one environment this could yield the ultimatesoftware tool capable of enabling operators to makedecisions with confidence in the outcome.

Technical literature reveals a trend towards practicalhow-to protocols that provide the maximum benefit ofaccumulated experiences, eliminate knowledge inconsis-tency and set measures of quality control. Although themotive behind each protocol is different, the need andbenefit of standardization are still apparent. This is espe-cially emphasized if mathematical model simulations areto be introduced into traditionally operated plantsbecause a great effort must be dedicated to adjust rou-tine operating measurements for model use.

References

Bahgat L. 2000. A knowledge-based decision support sys-tem for an activated sludge wastewater treatmentplant. Master’s thesis, Department of InformationTechnology, Institute of Graduate Studies and research,Alexandria University, Egypt.

Billing AE, Dold PL. 1988. Modelling techniques for bio-logical reaction systems. Part 1: mathematical descrip-tion and model representation. Water Sci. Technol.14:185–192.

Copp JB. 2000. The COST simulation benchmark –description and simulator manual, COST (EuropeanCooperation in the field of Scientific and TechnicalResearch), Brussels, Belgium.

Ekama GA, Barnard JL, Gunthert FW, Krebs P,McCorquodale JA, Parker DS, Wahlberg EJ. 1997.Secondary settling tanks, theory, modeling, design andoperation. Scientific and Technical Report No. 6, IWAPublishing, London, UK.

Gall RAB, Patry GG. 1989. Knowledge-based system forthe diagnosis of an activated sludge plant, p. 193–240.In Patry GG, Chapman DT (ed.), Dynamic modelingand expert systems in waste-water engineering. LewisPublishers, Inc., Chelsea, Michigan.

Giarratano J, Riley G. 1998. Expert systems: principles andprogramming. PWS Publishing Company, 3rd ed.,Boston.

Gujer W, Henze M, Mino T, Van Loosdrecht MCM. 1999.The activated sludge model no. 3. Water Sci. Technol.39:183–193.

Hanselman D, Littlefield BR. 2001. Mastering MATLAB 6.Prentice Hall, U.S.A.

Henze M, Grady CPL, Gujer W, Marais GvR, Matsuo T.1987. Activated sludge model no. 1. Scientific and

Technical Report No. 1. IWA Publishing, London, UK.Henze M, Gujer W, Mino T, Matsuo T, Wentzel MC,

Marais GvR, Van Loosdrecht MCM. 1999. Activatedsludge model no. 2d ASM2D. Water Sci. Technol.39:165–182.

Henze M, Gujer W, Mino T, Matsuo T, Wentzel MC,Marais GvR. 1995. The activated sludge model no. 2.Scientific and Technical Report No. 3. IWA Publishing,London, UK.

Hulsbeek JJW, Kruit J, Roeleveld PJ, Van LoosdrechtMCM. 2002. A practical protocol for dynamic model-ing of activated sludge systems. Water Sci. Technol.45:127–136.

Jeppsson Ulf. 1996. Modeling of wastewater treatmentprocesses. Ph.D. thesis, Department of Industrial Elec-trical Engineering and Automation, Lund University,Lund, Sweden.

Ladiges G, Kayser R. 1994. Applied off-line expert systemfor effluent, operational and technical problems ofwastewater treatment plants. Water Sci. Technol.30:157–174.

Liang YD. 2000. Introduction to Java programming withJbuilder 3. Prentice Hall, U.S.A.

Makinia J, Swinarski M, Dobiegala E. 2002. Experienceswith computer simulation at two large wastewatertreatment plants in northern Poland. Water Sci. Tech-nol. 45:209–218.

Martin K. 2001. Object-oriented programming in JAVA.Prentice Hall, U.S.A.

Morgenroth E, Arvin E, Vanrolleghem P. 2002. The use ofmathematical models in teaching wastewater treatmentengineering. Water Sci. Technol. 45:229–233.

Rosen C. 2001. A chemometric approach to process moni-toring and control with applications to wastewatertreatment operation. Ph.D. thesis, Department ofIndustrial Electrical Engineering and Automation,Lund University, Lund, Sweden.

Samuelsson P. 1998. JASS: a Java based activated sludgeprocess simulator. Master’s thesis, Systems and ControlGroup, Uppsala University, Sweden.

Spanjers H, Vanrolleghem P, Nguyen K, Vanhooren H,Patry GG. 1998. Towards a simulation-benchmark forevaluating respirometry-based control strategies. WaterSci. Technol. 37:219–226.

Takacs I, Patry GG, Nolasco D. 1991. A dynamic model ofthe clarification-thickening process. Water Res.25:1263–1271.

Water Environment Federation. 1996. Operation of munici-pal wastewater treatment plants. Manual of practiceno. 11, vol. 2, 5th ed. Alexandria, Va.

Received: January 22, 2003; accepted: June 4, 2004.


application of activated sludge models in traditionally operated...

Documents