2. Related Topics in Simulation, Process and Automation Technologies
2.3 Current Process simulation systems
2.3.2 Apros/Apms
Apros (Advanced PROcess Simulator) is a dynamic process simulation tool developed by VTT and Fortum (Apros 1999). The development of Apros software started in 1985. At the beginning, the model libraries were developed
for nuclear power plant simulation. Later on, support for the simulation of a
conventional power plant and pulp and paper processes was added. The pulp and
paper version of Apros is called Apms (Advanced Pulp and Paper Mill
Simulator) (Niemenmaa et al. 1998). Apros was originally developed in the VMS and Unix environments, but nowadays the Windows version of the software is most commonly used. Apros has a graphical design user interface in a Windows environment, Grades. The version of the Apros software used in the evaluation is 5.03.
Q1: The General architecture for the Apros system consists of Apros simulation
server and client programs that communicate with each other using a TCP/IP-
based communication library known as ACL. Client programs can have data connections and command connections to Apros simulation server. Graphical design user interface Grades is one example of a client program.
Q2: Model configuration with Apros is modular. The user selects the process,
automation and electrical components from a toolbar and places them on a canvas (or net according to Grades). The user sets the values for the parameters of the component and connects it to other components. Both unit operations and streams are modelled as components (or modules in Apros). Reuse is achieved by introducing a mechanism for the user for transferring the modelled components on a canvas into a higher level component. The user can draw a symbol for this new component and he can export the Apros definitions for the component in a textual format. The graphics is also exported but in a binary format. This set of information can be later imported into the system and reused (template-based approach).
Q3: The user can program his own numerical solution algorithms to Apros using
an external model mechanism. External models are dynamically linked libraries
programmed with C/C++ or Fortran (there are examples and documentation for these languages). The functions programmed by the user have access to the variables in the simulation database of Apros and the routines are called after
each time step during the execution. The mechanism does not limit the access to the variables inside a particular unit operation but the routine can access all the variables in the simulation database. The mechanism is very powerful but also vulnerable to coding errors. There is no specific reuse mechanism for the external models. Of course, the models and their definitions in the database can be copied from one user to another, but they do not obey any standards for the usage in other environments. The automation library of Apros also includes a programmable component type. The user can add simple functionality to the simulation model by using this component type. The component supports an expression language similar to the language used in corresponding components in digital control systems. Using the components of the automation library the user can, of course, build new simple process models. This is, however, a different kind of extensibility. Ready-made solution algorithms are combined to produce new ones, whereas in the external model mechanism entirely new solution algorithms are programmed into the environment.
Q4: There are no specific configurational co-use mechanisms between Apros
and other process simulation tools, control systems or process design systems. The best way to create tailored connections between other systems is to use
Apros command queues. These are text files containing Apros database
definitions. Apros can dump the content or a sub-content of its database into a queue file. The queue file can then be further processed for use in another system. This kind of tailored co-use can be bidirectional.
Q5: During the simulation execution Apros can write its simulation results into a
file or send and receive data through TCP/IP data connections. The data is sent
and received in data blocks. Among other things this mechanism allows packing of the binary signals. This may be useful in large projects, e.g. in nuclear power plant training simulators. The number of signals handled after every time step (e.g. 100 ms) in real time simulation can be around 30 000. Apros has also an OPC server built on top of the TCP/IP-based data connection. The OPC server is a data client for Apros and exposes the simulation data for other applications through the OPC interfaces.
Q6: Apros is a single user system during the model configuration. Even though
it may have several command connections linked to it, there is no support for handling different users accessing the same parts of the model. There is also a
limitation that only one simulation run can be executed in one go. However,
several users could be running the same simulation and observing the same
values from different user interfaces. This may be useful, for example in a situation where a trainer is observing the simulation through his own user interface and an operator is using the operator station for operating the simulated process.
The user interface of the client can be located in a different host than the simulator both during the model configuration and during simulation. However, usage over the Internet may be difficult since often the TCP/IP communication ports cannot be opened because of firewalls and other security reasons. The
execution of the simulation can also be distributed. Apros can be synchronised
by using the data connection. In this way, two or more Apros processes can be installed to different hosts and they can calculate parts of the same process in parallel.