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.
www.andritz.com 2 of 16

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”.
www.andritz.com 3 of 16

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.
www.andritz.com 4 of 16

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:
www.andritz.com 5 of 16

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.
www.andritz.com 6 of 16

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.
www.andritz.com 7 of 16

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
Duration : 1 week
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
Duration : 1 week
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.
www.andritz.com 8 of 16

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.
www.andritz.com 9 of 16

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.
www.andritz.com 10 of 16

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%
www.andritz.com 11 of 16

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.
www.andritz.com 12 of 16

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.
www.andritz.com 13 of 16

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
www.andritz.com 15 of 16

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.
www.andritz.com 16 of 16