Sunteți pe pagina 1din 9

Hyperion Systems Engineering Ltd.

DATS Training Manual V. 1.4.3



This is the first draft of a document aiming at introducing dynamic model development to junior
engineers in a systematic way. The proposed approach is empirical in nature and should be viewed
as an educational tool for inexperienced modelling engineers. The general guidelines discussed
follow the hierarchy of steps for Otiss model building (smaster, para, data reduction,
commissioning/steady state, testing) with the addition of two preliminary steps called process
understanding and nodal diagrams thereafter. In fact, the main idea proposed here is that good
dynamic model development requires good understanding of all aspects of the underlying process
(physics, control system philosophy, critical design elements, etc.).

Process Understanding
Before anything else, the modelling engineer should take a good look at the PFD/PID material
for his PAM and identify the scope/function of his/her system. The following items should be
of particular importance:

The component slate for the PAM.

Is this a multi-component system? This will determine the steam type used in the dynamic
simulation. Can the system be approximated by pure water? Stream type 18 should be used
in that case.

The phase of the PAM.

Is this a single or multi-phase system? At which operations within the PAM would one
expect more than one phase? The associated vessels and nodes would then need to have
appropriate Ksets to be modelled correctly. Furthermore, would reverse streams be needed?
(Reverse streams will be critical in gaseous systems).

The number of input streams to the PAM.

These will normally originate from upstream PAMs, and need to be modelled using

The number of output streams from the PAM.

These might become feeds to other PAMs. Therefore, the modelling engineer will later need
to create a list of the associated flow calculators and the boundary conditions used (fixed

Hyperion Systems Engineering Ltd.

DATS Training Manual V. 1.4.3

pressure boundaries). When accessible, the related PIDs should be consulted for the actual
tag names of valves.

The number of recycle streams within the PAM and their significance.
Some of these streams will be NNF (normally no flow). Others may have significant flows
associated with them. The engineer needs to know that the latter are more likely to cause
commissioning problems and be prepared to deal with them later.

The function of all control loops within the PAM.

This knowledge is essential in subsequent model development. Certain control valves will be
fully closed at steady state (i.e. pressure relieves). This realisation, along with knowledge of
the valve failure mode (FC/FO) will later enable the engineer to commission the control
loop properly (action, expected controller output, etc.).

The action of three-way control valves within the PAM.

Three way valves usually reduce their opening for their first input stream, while increasing
their opening for their second input stream. In certain cases, though, both inputs might be
affected similarly. This needs to be clarified beforehand.

The action of split-range control schemes within the PAM.

The same considerations apply here. Is the controller signal to be equally split, or is an
algebraic function to be used? If so, what would be a sensible one?

The placement of manual blow-downs on vessels within the PAM.

This information will be utilised during testing.

The placement of orifii (pressure relieves) within the PAM.

This will again become crucial in dynamic testing. It might also affect commissioning, if the
selected pressure profile and orifice set points have not been selected in a consistent manner.

The placement of P, T reading instruments (transmitters) within the PAM.

This might indicate the need for specific pressure node placements within the model, in areas
where a mixer/splitter would otherwise be adequate.

The placement of check valves within the PAM.

This will indicate the need for reverse streams. All check valves whether explicitly marked
in yellow or not should be modelled unless otherwise specified by the project leader.

Nodal Diagrams
With this process knowledge, the engineer can now proceed to the creation of nodal diagrams
for his/her PAM. Nodal diagrams need not be over-tidy, computerised, or print-quality
documents. They should allow for decent quality photocopies and faxes, though. Special process
equipment that can only be modelled using a complex arrangement of OTISS blocks (e.g.
modelling of a steam ejector without usage of the EJECTHC block) should be discussed with

Hyperion Systems Engineering Ltd.

DATS Training Manual V. 1.4.3

the lead engineer and an acceptable approach should be decided upon before any nodal diagram
In the drawing of nodal diagrams, the engineer should have the following general rule in mind:

Only blocks directly contributing to stream connectivity within the PAM need to be shown
on the nodal diagram.
This eliminates MOTLAG and MOTOR blocks and all kinds of logic blocks from being
presented on the nodal diagram. PIPEFLASH blocks, on the other hand, should be explicitly
shown on the nodal diagram, since their two output streams (the flash vapour and liquid)
form the inputs to subsequent knock-out drums, separators, and pressure nodes. Similarly,
PROPSET blocks should be shown on the nodal diagrams.

Stream numbers (both internal and external) should be shown on the nodal diagrams, along
with network and node numbers for all pressure nodes.
Project-specific numbering conventions should be carefully reviewed before any nodal
diagram creation. The standard modelling guide conventions should be adhered to if not
overridden by project specific ones.

Simplicity is always an issue, and unnecessary pressure nodes should be avoided wherever

Pressure nodes can sometimes be eliminated by smart usage of the SERVAL block.

Pressure nodes carrying no P, T transmitters can usually be substituted by


Isolation valves before other flow calculators (i.e. pumps) might be treated using logic,
avoiding the placement of an extra pressure node between valve and pump (example to
be provided).

Tanks are not pressure nodes; the only exception involves tanks open to the atmosphere.

Unnecessary stream splits should also be avoided.

Take a KODRUM for example. The PID indicates a single liquid outlet, which is split into
two streams later on. In OTISS modelling, two liquid streams can be directly taken out of the
liquid node of the KODRUM. Unless project-specific holdup protection on the combined
stream is to be used, two separate liquid streams and no splitter would be the preferred
modelling approach.

Mixing of feeds to vessels should be carefully reviewed.

Inert gas feeds (N2) can safely be linked to the vapour node of the vessel. If internal flashes
are present in the vessels, liquid feeds can be directly linked to the liquid node of the vessels.
All other two-phase feeds should be mixed and flashed before entering the vessel.

Two more points concerning flow calculators (valves) follow:

Flow calculators at PAM boundaries should not be given arbitrary names.


Hyperion Systems Engineering Ltd.

DATS Training Manual V. 1.4.3

In almost all cases, the engineer can look through the process PID folder and identify all
valve tag names related to streams exiting his PAM. The same holds for utility (water/steam)

Usage of dummy flow calculators (no top) should be avoided.

If a manual valve exists on the PID (whether marked-up or not), a MANVAL block should
be used to model it. Imaginary valves are acceptable only when no valve is shown on the
process line at all.

Smaster File Creation

Smaster creation should follow nodal diagram completion. The standard rules of smaster
creation are covered in the modelling guide and will not be duplicated here. Only a few
guidelines will be given:

Standard or project specific naming conventions should be adhered to religiously.

Mixed usage of block suffixes is not allowed. As an example, simultaneous usage of S1 and
S51 suffixes for SUM5 blocks should be avoided.

A list of required standard modelling techniques should be compiled before any smaster
editing. A complementary list of project-specific modelling techniques should also be
prepared. Unspecified implementation issues should be cleared with the project leader

Smaster connectivity should be checked until the modelling engineer is certain that his/her
model is error-free in this respect.

All vessels and tanks should have holdup protection schemes implemented. For TANK1
blocks, the second block input (flow out of tank) should be the result of the COMPARE
block used for holdup protection.

It is crucial that all flow calculators are linked to their up- and down-stream pressure nodes
in terms of the proper node pressure variables. These should not be free variables (except
for fixed pressure boundaries, of course). This way, the model will display the proper
dynamic response.

The placement of EQAL blocks for holdup protection should be carefully reviewed. The
engineer should ensure that EQALs do not hinder the models dynamic response (as a
general rule, holdup protection should follow flow calculator declarations in smaster).

The control loop connectivity should also be checked. Transmitters should read valid,
existing process variables; controllers should receive existing transmitter signals; and control
valves should be linked to valid controller outputs; typos can be costly here.

All pressure nodes should be associated to valid network (solver) flags. Usage of free
variables here (or typos in the flag name) will undermine the models dynamic behaviour.

Para File Creation


Hyperion Systems Engineering Ltd.

DATS Training Manual V. 1.4.3

Para files should be prepared in two stages. A skim version containing only stream numbers,
network/node numbers, and execs should be prepared first. The .EXEC parameter should have
a global negative value. This can be globally set within the pdef/jpdef utility (Unix/Windows
NT). The model can then be loaded and the error log checked. A stream_index report should
also be generated at this point. In the stream_index file, most streams will be associated with two
blocks. Feed and exit streams will be associated with one block only. Streams that are being
flow-set may be associated with three blocks, where the extra third block is a FLOWSET.
Streams associated with more than three blocks will usually be in error (in very special cases, it is
possible to have a stream connecting two process blocks in the usual fashion while providing the
feed to extra process blocks, but this is beyond the scope of this appendix).
A second para file version incorporating standard block parameters (from a project-specific
checklist) should follow. Before any commissioning, the engineer should check that:

All network solver flags referenced in smaster actually correspond to valid para blocks.

All node numbers are unique (no duplicates).

All stream numbers are unique (no duplicates).

All standard parameters from the checklist have been implemented.

All standard parameters not in the checklist have been given sensible values and

The errorlog is clean (certain warnings on default parameter usage are acceptable at this

Data Reduction
The notion of data reduction usually refers to actual block data reduction (pumps, compressors,
heat exchangers). In this document, the concept will be stretched to encompass material balance
information and reduction.
In conservative data reduction, the following points are critical to successful model development:

All missing equipment data are flagged as early as possible and documented.

PFD/PID design points are used to generate default curves for pumps/compressors, for
which DS (datasheets) are missing.

PFD/PID heat duties can be used for heat exchangers in view of missing DS.

Manual and isolation valves can be sized according to the TK BALL valve tables.

Control valves can be sized according to the READY RECKONER tables, or the Valtek

All PFD/PID data is respected (vessel sizes, pump design capacities/head, etc.).


Hyperion Systems Engineering Ltd.

DATS Training Manual V. 1.4.3

In the broader sense, data relating to process material/heat balances have to be reduced from
PFD material balance sheets to be used later in the commissioning stage of the model. With
respect to this task, the following are useful:

Major stream missing info is flagged and documented.

PFD stream info is used in the absence of dedicated MB sheets, ASPEN3+ runs, etc.

DS info is also valuable in determining stream info.

Inconsistencies between steady-state simulation runs, PFD info, and DS values are
sometimes to be expected. The lead engineer will determine the order of precedence. Steady
state simulations will usually be the point of reference.

The date of PFD/PID and DS information is important. In the absence of any other clue,
the most recently dated material is more likely to represent the actual process inventory data.

Utility stream info may be found in separate utility MB sheets.

Given a clean para file (no stream connectivity errors), the engineer can proceed to PAM
commissioning. There are a couple of additional considerations that need to be addressed here:

A pressure profile has been selected for the process from DS info / PFD info / ASPEN+

The pressure profile is consistent with orifii set points usually shown on PIDs. As an
example, the operating pressure of a vessel cannot be set to 20 bara, when there is clear
evidence on PIDs that a PSV on the same vessel opens at 19 bara.

The pressure profile is consistent with equipment design pressures. Design pressures indicate
maxima (upper bounds) on the operating pressure envelopes, and they should never be

The stream flows for all major PAM streams are known.

Different engineers follow different approaches to the commissioning of their PAM. The
straightforward approach, starting from the first unit and sequentially proceeding to its
successors is not always valid for large, convoluted projects. The model may then have to be
broken down into subsystems of manageable size. This divide and conquer technique can be
particularly useful to inexperienced engineers.
Genfeeds can be used temporarily at the subsystem interfaces, only to be removed when all
smaller models have been successfully commissioned.

Steady state simulation package. ASPEN+ reports include flow-sheet connectivity by blocks
and stream lists containing F, T, P, H, vapor fraction, and composition.


Hyperion Systems Engineering Ltd.

DATS Training Manual V. 1.4.3

The subsystems, assuming they are sufficiently independent from each other, can be placed on
different solvers.
The choice of network (solver) boundaries should be based on common sense. As an example, if
a differential pressure transmitter reads the pressure difference between nodes A and B, these
nodes may intuitively be placed under the same solver network.
Various process elements can be tested during commissioning. The most important include:

Flow calculator dynamics. Even with the solver off, flow calculators should be checked for
valid suction and discharge pressure inputs.

Controller actions and valve failure modes. Particularly if there is some doubt on a particular
controller action, commissioning is the right phase to experiment and investigate. Of course,
as it was mentioned before, all control loop functionality should ideally be cleared

Holdup protection schemes. Checking during commissioning can significantly reduce

debugging at later stages and help avoid complications during dynamic testing.

Orifii set points. Ideally, these should have been assigned sensible values and they should not
open during commissioning. When in trouble stabilising a model, orifii can be shut off
(negative EXEC) temporarily.

Spare pump operation. Spare pumps will be closed at steady state, but their proper opening
and closing should be checked during commissioning anyway.

Pressure node vapour fractions. If there is evidence of two-phase behaviour, internal flashes
should be placed on the suspect nodes.

Lines that are NNF (normally no flow) need to be commissioned, too. Open the associated
manual valve and then close it again. This is the only way to initialise neighbouring pressure
nodes, tanks, etc. NNF lines should have MANVALs, no dummy flow calculators; the concept
of a dummy flow calculator with zero _AV is not acceptable modelling.

Steady-State Testing
The dynamic response of the system should be anticipated before any dynamic testing is
performed. With adequate process understanding, and following proper commissioning, it
should be straightforward to device simple and efficient testing procedures for the system at
hand. Particular weight should be placed on:

Feed flow reduction/shut off. How will the system respond to a rapid change in the feed? Is
the pressure profile responding sensibly? As an example, if the feed to a slug-catcher is
stopped and the vessel pressure does not go down, there must be some fundamental
modelling flaw to be discovered in the system.

Control loop response. If the set point of a temperature controller is decreased, how does
this affect the provision of say cooling water to the associated heat exchanger? If the

Hyperion Systems Engineering Ltd.

DATS Training Manual V. 1.4.3

cooling medium supply does not increase, then the control loop action must be wrong, or
some sort of smaster connectivity bug must be present in the model.

Control loop oscillatory behaviour. If a control loop is slightly perturbed, and assuming that
all control loop characteristics are correct, how does the disturbance evolve in time? Is it
amplified, or does it fade away gradually? Instability might indicate the need for control
parameter tuning (i.e. making the controller slower).

As mentioned before, the trivial tasks of testing holdup protection schemes, spare pump
logic, orifice response, exchanger blockage and fouling, etc. should have been addressed at
the commissioning stage. This is not implying that formal testing of the elements above
should not take place.

For most conventional processes, a general classification of system tests can be applied:

Feed variation tests. These involve increasing/lowering the feed flows by say 50%. More
severe variations can be attempted, depending upon internal testing requirements.

Warm shutdown. This test involves stopping the feed flows and heat inputs completely, but
not waiting for the process to reach ambient conditions in temperatures and pressures.
Therefore, manual blow downs may not be performed.

Cold shutdown. Same as above, but lowering pressure boundaries to atmospheric and letting
temperatures to ambient.

Warm start-up. Restoring the steady state of the process from a warm shutdown.

Cold start-up (BLACK START). Restoring the steady state of the process from a cold

Control loop tests. Vary set points and examine system response.

Orifii tests. Lower set points and restore. Apply leakage malfunction if desired.

Heat exchanger tests. Apply blockage and fouling. Vary utility flow.

Vessel drain tests. Open drain valves and restore.

Control valve tests. Fail valves open/close/stuck and restore.

Pump tests. Stop and restart. Start spare pumps too.

Special testing procedures may be needed for particular systems. In closed-loop systems, for
example, the concept of feed flow shut-off is not applicable. In utility systems (such as cooling
water loops), specific tests that would make sense would be related to lowering/increasing
consumer duties.

In conclusion, the development of a dynamic model should be viewed as a structured activity
bringing together process understanding and specific Otiss modelling techniques. Taking the
time to review the process carefully and clarify its functionality is the number one priority and

Hyperion Systems Engineering Ltd.

DATS Training Manual V. 1.4.3

prerequisite to the creation of a solid dynamic model. Junior engineers are therefore encouraged
to acquire as much process knowledge as possible prior to any model development activity.

Given a model you have previously worked with, revisit it and try to see whether the guidelines
of this document have been applied. This can be done with pencil and paper (no need to make
extra runs or re-commission anything). At the end of this review, write down an informal report
(this can be hand-written) identifying areas where you have benefited from the study of this
guide, points that you overlooked when you first developed the model, and elements of the
model development process that are still unclear to you.