Analyzing Plant-Design Scenarios

Project Scope

• For a typical project:
• 425 tags
• 8 screens, 6 popups
• 1 client
• 0 alarms
• 1 OPC DA device (Kepware)
• Standard Architecture
• MSSQL Server, single instance
• Approx. 3,700 points of historical data logged

Project Overview

For this project, ANDRITZ Automation used Ignition to create an engineering tool that performs detailed analysis of the preliminary design of a plant. ANDRITZ creates an engineering design model of the plant in its proprietary simulation software called IDEAS. Then, Ignition controls the execution of a multitude of design scenarios and aggregates the results for the user, graphically presenting the impacts of design choices on parameters like plant throughput and energy consumption.

Automating scenario execution and reporting has allowed ANDRITZ to assess process design options in more detail and at a much earlier stage in the project than would have been possible using traditional engineering methods. Having deployed this application on several projects in the pre-feasibility stage, ANDRTIZ has been able to demonstrate conclusively why certain design choices are superior and other options should not be used.

Being able to subject a design to a wide range of operating conditions (like ore type and plant throughput) gives a greater degree of certainty at a very early project phase. By excluding inferior design options early, customers can prioritize their engineering hours and avoid costly changes later in the project.

Process simulation software has long been an effective tool for validating plant design in many industries; a model is constructed in software and process engineers use it to verify a design. Typically, engineers use a model to test a design hypothesis by setting a value (like a crusher size) and then running the model under various ore types and throughputs, monitoring the impact on the process to determine the optimal design choice.

Historically, running scenarios and gathering data involved a number of manual steps which, for budget and schedule reasons, significantly constrained the number of design scenarios that could be run.

To solve this problem, ANDRITZ Automation used Ignition to create a supervisory layer which sits on top of ANDRITZ’s proprietary IDEAS simulation software. The Ignition layer allows the user to define which variables in the model they are interested in varying, and the range for each. Ignition then automates the scenario execution, accumulating results in a database. After the scenario set is complete, tables, charts, and reports allow the engineer to assess the impacts on the process of each design variable.

Once the user has entered the variables of interest, scripts create the scenarios to run and load them into a database. A typical scenario set has between 40 and 200 scenarios and will take 2-10 hours to run.

Sequential Function Charts, or SFCs, manage scenario execution. When a scenario set is started by the user, the SFC fetches each individual scenario’s parameters from the database, commands IDEAS to run, waits for the simulation to converge, gathers the results, and then moves on to the next scenario. In order to automate the execution of IDEAS software, Python scripting in Ignition uses XML-RPC (remote procedure call) to command IDEAS via the IDEAS Application Programming Interface.

Ignition collects process data from the model using OPC. A multi-transmitter OPC object in the model transmits flow, density, pressure, temperature, particle size (D50/D80), and percent solids from the inflow and outflow of every piece of equipment to UDTs in Ignition. Along with equipment power, these values are stored to a database at the completion of each scenario. For convenience, the Ignition tags are built automatically from an XML import of IDEAS model contents.

When the system is used for dynamic instead of steady-state analysis, a time series of the process data is stored. However, each scenario set refers to simulated time instead of wall clock time, such as 0-20,000 seconds after an instigating event. A custom historian is necessary so that simulation time and scenario identification can be used to compare the results of different scenarios by overlaying them on the same time scale.

Certain measured values, typically equipment power and any flows into or out of the plant, are assigned material types from a material cost database. This feature allows aggregation of, for example, total plant power usage or water consumption for each scenario.

Equipment details from the model are imported into the database via XML files and scripting. Tags are associated with database objects so that the operating conditions (minimum and maximum flow, for example) for each piece of equipment are saved. This data forms the core of equipment specification sheets, which are created using PDF reporting and exported to distribute to vendors for quotation as part of the capital cost-estimating process.

Ignition allowed us to efficiently create an application that replaces engineering hours with computation. Ignition’s suitability for rapid software prototyping, particularly the combination of visualization with powerful scripting and database integration, was key to the success of this project.

This solution is one of several unique pieces of software for which ANDRITZ has used Ignition as a platform. Beyond its capacity to create powerful HMIs, Ignition really is a powerful platform for creating a wide range of applications.