Aracruz Uses a Dynamic Simulator for Control System ... - Andritz

Aracruz Uses a Dynamic Simulator for 

Control System Staging and Operator Training 

By 

André Luis Bogo 1 

Patrícia Nunes 1 

Gabriel Hidalgo 2 and 

Donald Wayne Herschmiller 3 

Key words: Simulator, Dynamic, Pulp, DCS, configuration and training. 

ABSTRACT 

This paper provides a summary of experiences at Aracruz Celulose S.A. in applying a dynamic process 

Simulator to the challenges of distributed control system staging and operator training on the Mill “C” project 

in Espírito Santo, Brasil. The tasks of creating dynamic models for most areas of this world-scale market 

Kraft pulp mill were challenging with respect to schedule and complexity. 

The ability to import and export the actual control system configuration to-and-from the Simulator allowed 

not only a comprehensive check-out of the process models, but also verification of the process control 

strategy and the application programming composed to implement it. The entire control system was 

thoroughly prepared for start-up and the operators were trained to a high standard of readiness. 

These factors contributed to a comprehensive commissioning process and to one of the fastest and most 

effective start-ups yet witnessed in the industry. The benefits to the project are assessed in a qualitative way. 

1 Aracruz Celulose S.A. - Espirito Santo, Brasil 

2 IDEAS Simulation, Inc. - Vancouver, Canada 

3 Veracel Celulose S.A. - São Paulo, Brasil 

www.andritz.com 1 of 16

INTRODUCTION 

With capital expenditures of US$ 850 million (US$ 575 million for the pulp mill), Mill “C” will add 700.000 

air dry tons per year of market pulp capacity to the existing two-line Aracruz mill. The new line began 

operations on May 23, 2002, significantly ahead of schedule. 

The implementation plan for the Mill “C” project included an innovative partnering concept with the EPC 

(Engineer, Procure and Construct) process “island” suppliers and their various sub-contractors, in order to 

achieve common quality, schedule and budgetary goals. One noteworthy innovation within this concept was 

the development and use of a dynamic process Simulator. 

In mid-March 2001, the company which is now called IDEAS Simulation, Inc. of Atlanta, USA, was asked to 

proceed with process model development for the Simulator project. The Simulator project involved the 

development of dynamic process models in seven Mill “C” operating areas: Digester and Pressure Diffusers; 

Oxygen-Delignification and Screening; Bleaching; Chlorine Dioxide Plant; Pulp Drying; Evaporation; and 

Recausticizing and Lime Re-burning. 

The Simulator was aimed at assisting the project team in achieving an exceptional mill start-up and rapid 

ramp-up to full production. To do this, the Simulator was applied to the role of Distributed Control System 

(DCS) staging and operator training. 

Besides the project objectives, the Simulator can be used, after the start-up, to support operations by testing 

the effect of changes in the process, including process configuration, operating conditions, or equipment 

changes, and predict unforeseen process complications. In addition, the process control systems in each area 

can be analyzed, tested and improved, all before attempting changes in the field. 

WHAT IS THE SIMULATOR? 

The Simulator is a combination of mostly standard computer hardware and some highly specialized software. 

In short, the structure adopted by Aracruz consists of three essential parts: 

• The operator’s workstation, using exactly the same operator-interface graphics as in the real plant. 

• Specialized emulation software and hardware to run the DCS configuration, again exactly as it will be 

run in the field. 

• Specialized process modeling software to simulate the processes in the real mill, and standard 

computers upon which to run the models. 


A simplified view of the overall architecture of the system compared to the real life situation is shown in 

Figure 1, below. 

Figure 1 The Simulated and Actual Plants Compared 

At the workstation the operator has full use of the same screens that he will use in the real plant. If the process 

models are well executed, the process has much the same “feel” as the real-life process. Thus his window and 

his world are similar, if not exactly like his reality. 

Using the emulation software and hardware, it is possible to load a copy of the configuration taken from the 

field equipment. Thus the system replaces the DCS hardware process controllers (CP) needed in the real 

world, with the control logic in the Simulator functioning exactly as in the real-world hardware. In our case, 

depending on the size of the mill, or area configuration, it is possible to “replace” nearly one-half of a mill’s 

hardware CPs in just one emulation system. 

The virtual signals upon which the emulated DCS configuration code acts are generated by the process 

models. 

The next section in this paper will present an actual working example of part of a model developed for the 

project. This section is written primarily for the reader who has some background knowledge in modeling, but 

is unfamiliar with the modeling suite used. Those who are primarily interested in strategic issues can bypass 

this section and go directly to the sections on “STAGING THE DCS AND THE SIMULATOR” and 

“TRAINING OPERATORS USING THE PROCESS SIMULATOR”. 


DEVELOPMENT OF THE PROCESS MODELS 

General 

The modeling software, a proprietary product called IDEAS, was developed by our contractor specifically for 

dynamic process simulation. While it proved to be a competent and robust tool, IDEAS does require 

considerable training and practice, for a good process engineer to become a proficient modeler. 

Process models are created by graphically connecting pre-programmed “Objects” in a logical sequence on a 

“Worksheet”. The Worksheet looks somewhat like a process and instrument diagram (P&ID). The icons for 

many of the objects, or groups of objects, usually take on the appearance of a specific piece of process 

equipment, while the models themselves become functioning pressure-flow networks of pipes, pumps, valves, 

tanks and other equipment. 

Appropriately programmed, models can predict the operating characteristics of the process and track variables 

of interest. The modeling software allows the developer to combine discrete and continuous simulation on a 

single Worksheet. The solution engine uses first principles equations to calculate mass, energy and 

momentum balances across multi-component systems. One particularly valuable feature of the modeling 

software is its ability to interface directly with most distributed control systems. 

Objects 

An object, or a group of objects, possess an icon-style representation; a dialog box for entering and viewing 

equipment specifications and other data; and connectors, so that a number of objects can be assembled into 

models on a Worksheet. See Figure 2, below. Objects can be obtained from one of a number of libraries. 

Objects, in effect, emulate the behavior of specific parts of the process; from a simple mixing tee to a sizable 

piece of process equipment. Information is passed into the object through the input connectors where it is 

processed by internal computer code. The object transmits information, via its output connectors, to the next 

part of the model. 

Object Libraries 

In 

Fouling Fouling 

Factor 

Rejects 

Accepts 

Figure 2 Dynamic Pressure Screen Icon 

An Object Library is a repository for a group of pre-programmed objects. An individual library normally 

holds objects that possess a common purpose or which belong to an associated equipment family. A few of 

the objects used to build the Aracruz models have the following names: Pressure Screen, Macro Conveyor, 

Dynamic Wash Stage and Incompressible Tank. 


Worksheet Building - Featuring a Modern Commercial Pressure Washer 

The Wash Stage Object 

The DD Washer TM , a commercially available, multi-stage pressure washer, is one of the key pieces of process 

equipment selected for the Mill “C” fiberline. The Aracruz supply includes three different models of this 

washer, although some general principles apply. Fresh wash liquor is fed to the last zone of the washer. After 

passing through the pulp mat, the filtrate is collected in a chamber and pumped to the preceding zone of the 

washer. This counter-current washing continues until the filtrate exits the washer at the first zone(s) which see 

the incoming pulp. A vacuum suction zone follows the last washing zone, after which the pulp is discharged 

by means of pressurized air. Figure 3, below, shows one example of DD Washer TM internal flows. 

Figure 3 Drum Displacer Washer (DD Washer TM ) Internal Flows 

The Wash Stage object can be used to model each of the three zones of a typical washing operation; mat 

formation, displacement washing and vacuum dewatering. See Figure 4, below. 

Gas Shower R1 R2 Speed 

D1 

D2 

WASH STAGE 

Mat 

In Flush K1 Filtrate 

K 

Mat 

Out 

Figure 4 Wash Stage Object 

The modeler can select the appropriate washing zone by choosing the correct options from the Input 

Parameters tab in the object’s dialog box. This simple approach allows the modeler the flexibility of 

configuring any given commercial washer by combining appropriate Wash Stage objects to match the 

equipment design. The Wash Stage object’s computer code includes the following engineering concepts: 


Drainage velocity ( w ) equation: 

⎛ ρ ⎞ 

∆P ⎜ 

⎜1− 

c⎟ 

⎝ ρ ⎟ 

fib ⎠ 

w = − 2 2 2 

S µρ c kZ 

Where, 

v m 

3 

dp / dZ = pressure gradient across a mat of thickness Z 

S v = specific surface area of the fibers 

(m 2 fiber/kg fiber) 

µ = viscosity of filtrate (kg/m-s) 

ρ = mat density (kg mat/ m 3 mat) 

ρ fib = fiber density (kg fiber/ m 3 fiber) 

c = consistency of the mat 

(kg fiber/kg mat) 

w = linear velocity of the filtrate (m/s) 

k = Kozeny factor 

Assuming that curvature, compared to the thickness, of the mat within the wash zone is small, then the mat 

can be modeled as a flat surface. Consider a flat section of mat of thickness Z m , width y , arc length S , as 

shown in Figure 5, below. 

Consistency equation: 

C 

B 

RZmC A 

= 

Z + Z C ( R − 1) − w( 1− 

C ) dt 

m m A A 

Figure 5 Flat Mat Surfaces in Wash Zone 

Where the new consistency CB at the end of a zone is a function of the consistency CA at the beginning of 

the zone. When this calculation is repeated over all N z slices in the zone, we can obtain the consistency 

profile over a full wash zone. 


Washing calculations: 

( 100 C) 

C 

DF = W / P − − / 

Where DF is the dilution factor (mass of water per unit mass of pulp that enters the filtrate system), W is the 

mass flow of water per unit time, P is the mass flow of pulp per unit time and C is the discharge consistency. 

( C − C ) ( C C ) 

DR = / − 

f 

d 

f 

s 

Where DR is the displacement ratio, C f is the feed consistency, d C is the discharge consistency, and C s is 

the shower consistency. 

The DD Washer TM Hierarchical Block 

The DD Washer TM is built as a series of dynamic Wash Stage objects. The first Wash Stage object represents 

the formation zone, the next object, two or more displacement washing zones, and the last one, the vacuum 

zone. In addition, a Macro Conveyor object linked with an Incompressible Tank object represent the repulper, 

located at the pulp outlet side of the washer. 

A hierarchical block, or H-Block, is a collection of objects, which become a subsystem, or a significant piece 

of vendor equipment, in the Worksheet. To complete our washer example, a filtrate tank, vacuum tank, 

pumps, inlet valves and the standpipe also are joined to the H-Block connectors. The whole DD Washer TM 

subsystem becomes an integral part of the brown stock fiberline or the bleach plant area of the model. 

In developing the models, the essential engineering information was drawn from project documentation 

provided to Aracruz by each EPC supplier. When working versions of the models were achieved, the EPC 

suppliers were invited to witness trials and provide feedback on the completeness of models in their 

respective areas. 

In order to test the models, a rudimentary control strategy must be included in each model Worksheet. This 

strategy need not be as extensive, nor a duplicate of the real strategy as it will be “turned –off” when the 

actual DCS control logic is “joined” to the model during staging. 

Following some additional work, the models were ready for their role in DCS staging. 


STAGING THE DCS AND THE SIMULATOR 

Initial Plan 

During the course of Simulator staging activities in each process area, three important steps stand out: 

1. Mapping of DCS/Simulator inputs and outputs (I/O Mapping); 

2. Verification of the individual control loops; and 

3. Verification of the EPC operating procedures and final validation of the process models (the Joint – 

FAT). 

Foxboro 

Activities 

1st SaveAll 

AMEC Simulator 

Staging Activities 

Foxboro Pre - FAT 

(CP Hardware) 

Duration : Variable 

I/O Mapping 

Personnel : AMEC, Si ndus 

Duration : 1 week 

2nd SaveAll 

Fox App SW Fox App SW 

Foxboro FAT 

(CP Hardware) 

Duration : Variable 

IDEAS Mini - Sys te m IDEAS Mini - Sys te m 

Activities : build cross - 

reference database, 

finalize I/O addresses , I/O 

communications check 

Modifications to 

Fox App SW 

Initial System - W ide 

Check 

Preparation for Final Joint FAT 

Activities : Individual control 

loops and motor start - 

stops tested tes ted , Foxboro App 

SW & model pre - check , 

controller pre - tuning 

Personnel : AMEC, Si ndus , 

Aracruz Operator 


3rd SaveAll 

Fox App SW 

IDEAS Model 

Figure 6 Initial Information and Workflows during Staging 

Final SaveAll 

(CP Hardware) 

Fox App SW 

Final SaveAll 

(FSIM Softwar e) 

IDEAS Mini - Sys te m 

Joint Fox App S W FAT 

Activities : Area - wide start - up 

& shutdown witnessed by 

EPC Supplier & Foxboro , 

group starts tested ; changes 

made to Foxboro App SW 

Personnel : AMEC, Aracruz, 

Foxboro , EPC Supplier 


At the onset, we developed a diagram, which describes the flow of information and activities of the Simulator 

in relation to DCS staging. It is shown as Figure 6, below. 

To support this work process and the proposed schedule, we also developed three so-called "mini-systems". 

These systems were hardware abbreviations of our final system architecture, but they were able to run the 

same software for a single area. Later in the staging process we developed techniques to allow the staging of 

two areas using a slightly modified mini-system. 


DCS/Simulator I/O Mapping 

On the Simulator side, the first step executed is the mapping into the system of all DCS inputs and outputs. In 

this step, each I/O device in the process model and the matching entities in the DCS configuration must be 

aligned. The product of this activity is called the "Cross-Reference Database". 

The model developer accomplishes this activity, as the onus is on him to match the DCS system, not the other 

way around. The modeler needs only support from a DCS technician in obtaining an appropriate SaveAll. 

At this stage, the DCS configuration does not have to be a highly developed one. With his Cross-Reference 

Database assembled, the model developer could appear at staging perhaps three days before the finish of the 

conventional DCS contractor’s FAT, for a final pre-check of process model-DCS communications. 

Control Loops Verification 

After the construction of the Cross-Reference Database, the Simulator team is ready to begin the verification 

of configuration coding. In this step, the model developer must have the support of a DCS technician, for 

adjustment of control parameters. He also needs an experienced console operator to run the Simulator and the 

DCS contractor’s configuration coder, for correction of mistakes in the configuration that might impede the 

continuity of the checkout work 

However, if a more integrated procedure were to be used, we feel that a "control configuration ready for 

Simulator staging" must at a minimum be complete (no areas marked “to come”), including all features such 

as group starts and sequencing. It also must be pre-checked to the best of the coders´ ability. Extending 

conventional staging too long is a questionable use of resources. However, coming into staging without a 

complete control configuration is an even worse waste of resources. 

As soon as the console operator starts to execute the start-up, shutdown and emergency procedures of the 

plant, the real business of Simulator staging starts. 

Using ever more advanced SaveAlls (configuration loads) from the DCS side, individual control loops were 

tested, by trying to start the area. Motor start/stops also were tested and controllers pre-tuned. The work might 

seem to have been relatively routine, but it was made more complex by the existence of three types of 

possible “deviations”; deviations in the process models themselves, in the logic underlying the DCS control 

strategy and in the DCS configuration coding. Every deviation, or potential improvement, was logged on a 

formal, so-called, “punch list”. 

On the Mill “C” project, punch lists were augmented daily and delivered to the DCS coder for correction of 

outstanding items in the course of his work. As well, the coder might be asked to make emergency corrections 

of items blocking the progress of Simulator staging work. 

For each new EPC area, the Simulator had to prove to the uninitiated that it was a potent tool. In this regard, 

the punch lists became the focus. Either the items on it were valid, or they were not. The alternative of the 

EPC signing off on staging before the Simulator was employed soon became passé. As soon as the Simulator 

was used, mistakes that conventional checking methods could not find were revealed. 

As the work proceeded, it also became necessary to make modeling corrections or changes. Often, the 

changes made to the models were not to correct mistakes; they were more often aimed at achieving the 

desired process response, to accomplish training objectives. The demands on a model for staging are 

somewhat lower than for training, but step-wise changes were considered, and often made, to prepare the 

Simulator for training. The net effect was a higher fidelity Simulator for both purposes. 


In general, because loop testing did not involve the EPCs, but was essentially a check of the configuration 

coder’s implementation of the EPC’s control philosophy; the issues were identified only, and listed on the 

punch lists. They were usually held for the next step of the process, the Joint-FAT. 

As the work progressed towards a fully functioning Simulator, the Aracruz operators (later our Trainers) 

began to have an opportunity to take a more detailed look at the control philosophy, interlock strategies and 

the patterns of implementation, or slight variations in standards or norms adopted by each EPC supplier and 

his contractors. 

Joint Factory Acceptance Test 

In this last step of staging, it was again necessary to have the support of the model developer, the DCS 

technicians, the Aracruz operators, the DCS coder and, most importantly, the EPC supplier’s start-up engineer 

and ideally his lead area control specialist. 

In the Joint-FAT the majority of modeling problems were identified and corrected. In addition, we could 

address also the “held” questions on our punch lists; items concerning the EPCs control philosophy. 

In this activity, the EPC supplier was primarily responsible for verifying the faithful execution of the start-up, 

shutdown and other important emergency procedures. In most cases, we also were able to obtain detailed 

input from the EPC’s people about the control philosophy employed, process details and validation of the 

Simulator as ready for training in the EPCs area. 

Simulator Performance Issues - What do the Punch Lists Tell Us? 

The punch lists were generated at two steps in staging; after initial system checkout (mostly loop testing) and 

after the Joint-FAT. They identified mistakes in DCS configuration coding; modeling errors or suggested 

changes; control strategy errors or suggested changes in philosophy; and miss-specified or poorly 

communicated items. The lists are the essence of what was accomplished with the Simulator during DCS 

staging. 

Figure 7, next column, summarizes overall data for Simulator/DCS staging. The data shown are weighted 

according to the approximate level of effort that would be required to either correct or address the item. Note 

that the owner of each item determined the weighting for his items. 

Before we discuss the data, a brief explanation of what a punch list item actually means is in order. For the 

DCS coder, errors could be as simple as wrong addresses and screen errors to more serious disconnects, say 

the logic in group starts. For the model developer, errors would usually be divided into two categories; 

process conceptual errors (such as an incorrect reaction equation or wrong pump data) and logic errors (a 

wrong address). EPC items were 90 to 95% operator suggestions for control strategy improvement and 5 to 

10% errors in the control strategy. The later might be as simple as the wrong action on a valve to something 

much more complex. Aracruz items could be such things as DCS or control standards not correctly defined, 

or missing. 

As shown in Figure 7, the dominant items relate to control configuration coding, about 70% of all weighted 

errors. At least 50 to 60% of these errors were caught during loop testing, and most of the remainder surfaced 

in the Joint – FAT. 


Simulation 

Company 

18% 

Figure 7 Overall Punch List Data 

What is the value of catching these errors? Some of the errors are trivial, but others might delay the start-up of 

the plant or the continuance of operations until they are corrected. Still other errors might not stop the plant, 

but could lead to a drop in operating efficiency. Both of the last two categories might result in a loss of 

product quality. 

On the modeling side, most of the 

significant issues surfaced during the Joint – 

FAT. They were primarily issues that deal 

with the fidelity or truth of the model 

response. Modeling errors are usually not 

trapped during loop testing because the 

focus is on configuration coding. Fidelity 

issues are also likely to surface later as well, 

during training, when the focus of the team 

is even more on process response. 

A DCS configuration which could start the 

“virtual mill” was considered highly likely 

to be a configuration which would start the 

real mill. The virtual mill (in essence a 

dynamic process model, an area DCS 

control configuration and an array of 

supporting hardware and software) was at 

this point ready to be applied to operator training. 

General Statistics of Configuration 

Check Out Phase 

EPC 

Supplier 

14% 

Customer 

1% 

DCS 

Company 

67% 


TRAINING OPERATORS USING THE PROCESS SIMULATOR 

The Simulator training program was as comprehensive as we could make it in the time available. The primary 

goal was to allow the operators to become totally competent in the start-up and shut-down procedures. In 

addition, operating fault scenarios, some already used in staging, were installed on the system and Trainees 

were instructed to react to them as they would a normal task in a working mill. 

The advantage to Aracruz of this training was that the operators experienced a close to real life workout, but 

in a virtual setting. This setting eliminated any ill-effects on production, damage to process equipment, or 

negative effects on the environment. The training was provided well before we had to start-up the real mill. 

Training the Trainers 

In order to accomplish training on the Simulator, we decided to implement a concept of lead operators acting 

as Trainers for their peers. We nominated the best operators that we could find from the existing Aracruz 

Mills “A” and “B”. The operators were released from their duties and put through a rigorous program of 

schooling and work, to prepare them for their new role as Trainers in their assigned areas. 

A number of the activities were part of the conventional training and commissioning designed by Aracruz and 

the EPCs for Mill “C”. Our Simulator Trainers received this training alongside their colleagues in classrooms 

or other settings. The remainder of the training was specific to the Simulator, or actually consisted of work 

that we had to do to prepare the Simulator for training. 

The seven stages of development of our Trainers are described below: 

1) EPC training 

Under the EPC suppliers’ contracts, they were required to deliver a comprehensive classroom program to 

Aracruz operating and maintenance personnel. For each EPC area, the lectures were delivered over a period 

of about fifteen days, based upon eight-hour days, and were supplemented by the EPC-prepared Operating 

Manuals. 

2) Training Scenarios development 

The first involvement of the operators with the Simulator was prior to staging, immediately after EPC model 

checkout in Atlanta, Georgia. It involved the elaboration of training scenarios. In a general way, the scenarios 

were based on two causes; operational and equipment failures. 

3) DCS Staging and FAT 

The Trainers were involved also in the DCS contractor’s Factory Acceptance Test (FAT). That activity built a 

practical understanding of the control philosophy. 


4) DCS Staging using the Simulator 

Following the conventional FATs, the Trainers were employed on Simulator staging. This work allowed them 

to become familiar with the simulation software and to learn how to use the Simulator to verify interlocks, 

sequencing, the operation of valves and many other things. 

5) Joint-FAT 

The Trainer next played a key role in the Joint-FAT by actually running the virtual area. At the conclusion of 

this step, the EPC start-up engineer, in consultation with the Trainer and the development team, validated the 

Simulator as ready for training. 

6) Scenarios testing – a post Joint-FAT 

After validation of the Simulator in a given area, the Trainer and model developer pre-tested the scenarios and 

established such metrics as target response times and expected Trainee performance. By this time the Trainers 

were extremely well versed in virtually all aspects of the DCS, the controls and the Simulator. 

7) Training with IDEAS Instructor 

The Trainer was also taught how to use the Simulator “Instructor” software. This training was particularly 

important because, “Instructor” was used to launch the model and other application programs (it effectively 

starts-up the Simulator). It also allows the Trainer to login a student and keep an administrative record of the 

training. 

Operator Training Program 

In order to determine the minimum number of hours of Simulator training required for each area of the mill, 

we developed with the Trainer, a list of important activities and estimates of the time that we would need on 

the Simulator to accomplish them. We determined that the Trainee should complete these activities at least 

twice. 

For example, the training plan for the Bleaching Area is listed below: 

• Review of the main process differences and interlock strategies, in Mills "A" and "B" compared to 

Mill "C"; 

• Start-up from an empty system, in a manual mode, with water; 

• Start-up from an empty system, in a manual mode, with pulp; 

• An emergency shut-down of the plant; 

• Start-up from a full system; 

• Planned shut-down with a total emptying of the plant; 

• Start-ups and shut-downs in automatic; and 

• Evaluation of the training: start-up, shutdown and selected operating scenarios. 

The training schedule was based on training in pairs, with individual evaluations only. We also prioritized the 

program in some of the last areas by giving the front-line console operators as much time as we had available. 


Figure 8, below, displays the number of training hours for each area operator. In all, 52 operators, including 

the Trainers, received Simulator training. The configuration of the Simulator for ongoing training and other 

post start-up activities is shown in Figure 9, on page 13. 

Trainee Feedback 

Training Hours 

45 

40 

35 

30 

25 

20 

15 

10 

5 

0 

Cooking 

40 

Hours Training per Operator by Area 

Bleaching 

38 

Recaust/Lime Kiln 

24 24 24 

Evaporation 

Figure 8 Operator Training Summary Data 

Trainee feedback was very positive. In most cases Trainee evaluations were offered in considerable detail 

concerning experiences. There was a unanimous feeling that the Simulator had indeed helped them and had 

been important to the start-up of Mill “C”. In fact, EPC start-up engineers echoed these sentiments, remarking 

upon the ease with which the operators navigated the DCS screens and the confidence that they displayed in 

enacting the various start-up and shutdown procedures. 

ClO2 

Delig 

16 

Screening 

www.andritz.com 14 of 16 

16 

Drying 

11

OBSERVATIONS AND CONCLUSIONS 

The Simulator was purchased for the Mill “C” project primarily for the perceived values it would have in 

DCS staging and operator training. Did it pay its way? Or more specifically, did it help to produce a faster 

start-up and faster ramp-up curve? 

These questions cannot be answered fully yet because the start-up was less than one month ago. Nevertheless, 

this question still will be difficult to address in precise quantitative terms. The difficulty lies in the fact that a 

good start-up and a steep ramp-up curve are the sum product of many things: good planning and well- 

executed engineering throughout the project; good construction technique and superior execution; all facets of 

training (in addition to operator training); well-planned and executed commissioning and many other aspects. 

Figure 9 Final Architecture of the Aracruz Simulator 


The pertinent question is can one separate these and many more factors and assign realistic monetary values? 

On the Aracruz Mill “C” project, we believe that we executed many of these factors as well, if not better, than 

many who came before us. However, in addition, we had an experienced and well-educated team of operators 

and maintenance people, drawn from the Mills “A” and “B” and a smoothly functioning management and 

supervisory structure already in place. 

These aspects acknowledged, we believe that there is ample evidence to support the conclusion that the 

Simulator was a strong contributor to our overall success. The project was executed on an exceedingly tight 

schedule. It is arguable that without the Simulator as an incentive (to get ready for operating training) and as a 

prod (the team did its best to keep the pressure on to accomplish this) that we probably would not have done 

as well in getting the control systems ready, not just for start-up, but significantly for commissioning as well. 

The punch list items are “hard” evidence that we made the control systems more error-free. The lists 

constitute a body of real errors caught before commissioning and start-up. There were, in fact, many 

improvements made to the control logic as well. 

During commissioning, virtually no problems surfaced regarding the DCS and the control configuration. This 

advanced stage of readiness, we feel contributed to our strong commissioning performance, in that the team 

was free to concentrate on other aspects, primarily the physical ones. 

The mill start-up, from first chips to the digester to 

the first bale of pulp, proceeded continuously over a 

period of 45 hours, without a single control 

configuration stoppage. The first significant stoppage 

was mechanical in nature. In fact, at this time in the 

mill’s ramp-up, we still have not observed any 

significant problems with the DCS due to 

configuration errors in the areas prepared by the 

Simulator. 

From the first hour of the start-up, the operators 

exhibited a confidence and knowledge of the start-up 

procedures and the controls not seen before by many 

of the EPCs experienced start-up people. The 

operators’ familiarity with the DCS screens, the 

instrument tags, and the control and inter-lock details has allowed them to contribute on an equal basis with 

the EPCs start-up personnel. For the main part, the Aracruz operators “owned” the mouse from the very 

beginning and have never released it from their grasp.

Aracruz Uses a Dynamic Simulator for Control System ... - Andritz

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?