Not being as seasoned as most of the folks reading this, I have a more basic understanding of simulation.
I have found simulation particularly necessary when using unfamiliar system features. Reading up on how the function blocks change modes, initialize, and compute is great, but it often requires me to set up some parallel “dummy” or “shadow” logic to confirm to me how the logic will function with the live values. This is equally true for control scheme modifications and for new systems. Successive applications of similar logic usually do not require simulation in this way. Similar to others, experience leads us to “simulate” in our heads how the process will respond and react.
When possible, I have also enjoyed installing the logic and operator graphics for a new process before I/O installation. This is only possible if the process is standalone and new. By forcing and faking analog and digital signals, basic logic configuration can be checked out, such as control action, interlocking, and operator interface design. We still have to check it out during commissioning, but this first software FAT of sorts reduces the amount of errors and rework to be completed under the gun. This may seem like a no-brainer to those in consulting, but as a mill engineer, we are often scrambling right up to the deadline due to break in work and distractions.
I guess a third comment about basic simulation is about fluid flow and process dynamics. On my projects, the pumps, valves, instrument and piping is often designed by a project engineer or team. I know one engineer who uses fairly advance piping simulations to do her designs. She uses pump curves, geometry, and pipe properties to calculate all the pressure drops, head requirements, etc. I have never been on a project with her in which the controls were hard to get right. Simple systems like, flow loops, heat exchangers, and desuperheater, pressure controllers are all being designed by someone. I would consider the design of these systems to be a form of simulation.
Simulation usually involves help with understanding something and / or with testing something. Accurate and realistic simulation consumes time and resources so it’s always a good idea to carefully understand what you hope or need to learn from it. Writing a description of the objective(s) of the simulation is a good place to start and often the precursor to lots of long and sometimes intense lunches with interesting people in your organization. The critical question is, “What is it, exactly, that we need to know?” The obvious second question is, “OMG! Can we really do that?” followed by, “…and at the end we will know it’s right because…?”
Is it less expensive and/or more illusory than working directly with the involved process? Developing useful simulation can be pretty simple or unfathomably complex. There may be a PhD thesis hiding in all that stuff that will be involved. On the other hand, is monitoring and bumping the real process adequate for the requirements motivating the simulation? In my first major refinery project in process control one of the artifacts that was discovered in storage was an analog computer for part of the process made entirely from pneumatic devices. I’ve always wondered how well it must have worked.
Fundamentally, our science in process simulation and control is pretty good. If we understand what the process does and have some performance data we can characterize it with mathematics. Understanding is crucial and may involve adding some process data measurements to help us understand subtle nuances in what happens vs. what we expect. When we understand the functionality and mathematics it’s not difficult to simulate stimulations and watch them evolve on our computer monitor. Sometimes there’s a lot to learn, but that can be a good thing.
Creating realistic conditions for testing presumes we know enough to produce realistic perturbations. I used to save data files from the operation of processes I worked on to facilitate creating things like realistic noise patterns. There are books about various kinds of noise and how to model them. Modeling common random noise isn’t difficult but sometimes there are process inter-relationships that result in condition-specific periodic noise. All this suggests that the object of the specific work assignment might not be as “typical” as the broader science foresees.
In modeling, an important step involves comparing model performance to process performance over the pertinent range of conditions. If it seems likely that might be especially difficult or expensive it might be useful to take a deep breath and rethink exactly what you need to meet the motivating requirements.
I greatly appreciate the diverse responses.
Of course, I believe that simulation can be very important in testing and evaluating novel control approaches, which is what my academic research career has been about. (It is a one-upmanship game of publishing a control approach that is better than what the other guy published. And what I find embarrassingly lacking in academic publications are credible simulation demonstrations.)