Why simulate at all? From a control systems engineer's viewpoint, it is helpful to be able to predict the dynamics thereby gaining the knowledge of how loops may behave as well as allowing the simulation to be used as a training tool. The chemical engineers want to have some data to support the plant design and a simulator will help justify equipment design and sizes.
I have been asked to sit in on many discussions and vendor presentations about simulators. The subject comes up about what type of physical property database to use or how their product interfaces to the users database or how to enter physical and chemical properties of compounds not in their database. Clearly, this is the single most important factor from the chemical engineering simulation viewpoint. They usually divert their discussion to the DIPPR database while my mind keeps wondering about the dynamics that they say they have, usually as an option. Most of these products require a large cash outlet as well as ongoing customer support from some hot line or email service.
When you use one of these simulators for control, there are some watchouts; does you simulator actually simulate the following:
Can the dynamics simulate true deadtime? This is important because if it weren't for deadtime, most process control engineers would be out of a job. The control blocks should emulate real time as much as possible and therefore need deadtime. If your simulator does not do deadtimes, do not give up, it must do first order filtering. Just add multiple first orders in series, which looks like a first order with deadtime. This may not be sufficient, as I will explain later.
Noise simulation: This is necessary where analytical control is being implemented, noise needs to be filtered which adds lag to the process. The simulator should be able to add Gaussian noise with an adjustable standard deviation. This is very important for analytical data. Remember if the process model is only 85% accurate, it is good enough for process control. Frequently other engineers are very possessive and not willing to let others see the model because if is not accurate enough. For control purposes, accuracy is not required, just some overall dynamic behavior. The difference of 10% one way or another usually doesn't effect control simulations. Remember the objective of the simulator is to show the approximate behavior, and test various control strategies.
Simulated Physical Properties
This is the major watch out one should have with commercial packages. In order for the simulator to produce good results, you need a good estimate of the physical properties. How do they get these properties in their database? They perform regressions on experimental data or they use some equations based on molecular structure. If the data is experimental, what data did they use? Over what range was the data regressed? Frequently the data entered is only based on a few points and well outside the range where you may want to run your simulation. A good example of this is formaldehyde and water solutions.
An Actual Example
In order to minimize the size of a surge tank, a commercial package, with dynamic properties, was used to simulate a process chilled cooling system using a 50-50 mixture of ethylene glycol and water as the cooling medium. Forty percent of the system capacity is a batch process so there was some concern that a large surge tank is in place in order to allow the chiller to maintain the utility at the desired temperature.
Outlet Temperature: -4 degF
Cooling Media: 50-50 EG-H2O solution
Flow Rate: 600 GPM
Cooling capacity: 146 Tons
Piping: 1000 feet 6" SCH40
A commercial simulator was used to test the effect of various size surge tanks on dynamic response of the chiller's outlet temperature controller.
The first problem was the apparent inability of the simulator to calculate the viscosity of the glycol and water mixture. The simulator gave a viscosity several times the viscosity given by the vendor of the ethylene glycol and water solution. The density given was also in error. I question how these packages simulate liquid mixtures.
Once the simulation was configured, it showed that there was no control problem and that the return temperature changed instantaneously and as a result no surge capacity was required! This, of course, cannot be. The simulation failed to show the effect of the installed deadtime due to the piping. This turned out to be a very important criterion, because the liquid in the piping acted as surge capacity.
Piping should be considered both as a delay line and as surge. Consider the following:
The pipeline, 1000 feet in length (500-foot supply and return branches) of 6" SCH40 pipe
contains 1.5 gal/foot. When flowing at 600 GPM or 6.6 feet/second, the total delay per branch would be 500/6.6 or about 75 seconds. With a sample time of 5 seconds this would be 75/5 = 15 pipe segments with 500/15 = 33 feet/segment which is 33.33 feet/segment * 1.5 gal/foot = 50 gal/ segment.
In this case, it became necessary to simulate the pipeline as a series of 50 gallon tanks, the idea that deadtime can be simulated as a series of first order lags. Once this change was made, to the simulation, the simulator showed the first order effect, but still failed to show the effect of true deadtime. The system was finally simulated in EXCELÃ¢ to control the integration scan time, which was necessary to see the effect of the piping deadtime. Once the simulation was complete, it demonstrated that there is sufficient reserve of coolant in the supply and return piping to eliminate the surge tank. The following plots show the correct results of the simulation. Notice the dead time between the load temperatures.