A challenge with controls – specifically, with advanced control systems – is the installed characterizations of control valves. Often times the actual installed characteristics are different from what the published characteristics state, or, frankly, the information is no longer available. Additionally, a common practice is to manipulate the valve from 0 to 100% while watching the flow, but this is difficult to do while keeping the system online.
In this poster, I show a use case for the profiler and the simulator where historic data can be used to create valve characterization curves without impacting the plant operation. These curves can then be used to improve plant control networks or even help deploy advanced control systems.

Hello, my name is Drew Luby. I'm an analytics manager for ADM. Mike, go ahead.
Mike Lindley, data analytics engineer with ADM.
Today, we're going to be discussing our poster presentation titled Using JMP Profiler and Simulation to Characterize Installed Process Valves. First, a little bit of background about ADM. ADM's an agricultural processing company, and we utilize continuous flow processing in many of our plants. What that means is that we have usually liquids, gases, slurries traveling through our processes while we're constantly measuring parameters such as temperature, pressure, flow, and in this case, valve open percentages. There's a lot of data that comes in as time-based data and a significant amount of information about our systems as we do that.
One challenge that a lot of our engineers at ADM have with this flow system is process control. One way that we have found that we can improve process control, and a way to get to more advanced control methods, is to characterize our valves. To explain what I mean by that, control valves themselves can come in many different varieties. Some of the control valves, they can be a linear-type valve. There's a lot of different styles out there, but, in general, you can't assume that a percent increase in percent OP of a valve represents the same increase in the amount of flow.
What I mean is if you go from 20% to 21%, that's not necessarily the same increase in flow as if you go from 50% to 51% because there's a valve curve. If we're trying to optimize our control systems, it's helpful to characterize those valves, and that means dictate that curve that correlates the amount of change in flow as seen by a change in percent open of the valve.
Now, yes, valve curves typically are published, but there's two problems with that in real life. One is that we have a lot of installed valves that we don't necessarily have the documentation for, or we can't verify that what's installed is what the system says is there. Two, the installed curve is different than the published curve in that the published curve was done under ideal situations in a lab where they're giving it a constant pressure, and then they watch the change in flow across the valve.
What we really need is the installed characteristics of the valve in our pressure system installed in our pipe, et cetera, to see what the actual change in flow is at different percent OPs of the valve. That's what we're really going after, and that's the problem our engineers are trying to solve.
To explain that a bit more, here's an example problem. In this case, we have a source of a gas, and it's flowing through a control valve right here that we would like to characterize so that we can control it better. But you can see this system is quite complicated. From there, it flows through other valves and blowers and vessels, gets compressed, and ultimately comes through a flow meter.
Now, in an ideal lab, we'd have the valve and a flow meter right after it, and we'd be able to look at that curve. But we need to be able to characterize this valve to improve control given this whole system. We'd also like to characterize these three valves, too, these recycle valves. In this system, there are vents. If those vents were to be open, obviously not all the flow that went through that valve would also come out the flow measurement. We need to be able to do this at a time when all of the vents are closed. The simple solution is go to the plant, move this valve from 0 to 100%, and see what flow you actually get. But in reality, that's not going to be something we're allowed to do.
If we take this valve to 0, we're going to shut the whole system down. If we take it to 100%, it's possible we get so much flow going through that it causes one of these vents to open, and that could be a safety or an environmental issue. The plant is not going to let us experiment on the plant for this purpose. We need a way to get that valve curve as best we can without actually moving things in the field. That's ultimately the goal.
The way we are proposing to do this is that we can collect historic process data for all these flows and the pressures and the equipment statuses and the valve OPs, and then we can clean it all up and create contingent variables. When I say contingent variables, I mean when I'm looking at this system, I really only want to know that valve OP if this blower's running. If that blower's not running, then that valve doesn't really matter because we're isolated. You have to create those contingent variables. Essentially, there's a lot of preprocessing and cleaning work. Then you're going to build a model of the system that accurately reflects the way the system has operated in history.
Once we have that model, then we can utilize the profiler and simulation within the profiler to conduct simulation experiments giving those particular conditions we want to test. Make sure all the vents are closed, make sure the compressors are running, and test this valve as it goes from 0 to 100%. Once we run those simulation experiments, we can take those resulting data tables and fit a curve to that valve change in OP versus a change in flow. Then that curve is a numerical representation of the change in flow with every change in percent. We can utilize that to improve our control systems.
Real quick on the way we did this, use the Model Screening platform. It's handy to test a lot of different models at the same time. It also allows us to easily bring in curvature with the two-way interactions and the quadratics, and we know this would be a curvature-type problem, and utilizing K-fold cross-validation, which is handy with the amount of time-based process data that we have that we're building this model off of. Ultimately chose a neural net model, and you can see we get a pretty good fit, and the type of curvature we expect is showing up.
Now, I do want to point out for a later point that I do have extrapolation control on, and that's why some of these lines are cut short. These ones that are cut short happen to be those vent valves. You can see sometimes a vent is set to 0. That means it's closed, 0% open. Sometimes it's set to 100, which would mean 100% closed, and that's confusing. But we don't have a lot of data where those vents are open a lot, and that's why this shows up that way. It is important to use extrapolation control here so that we're not modeling a situation that doesn't reflect actual operation.
Next, using the simulator within Profiler, we can specify the conditions. Every other variable here is fixed aside from the valve that we want to test at that time, which we're going to range from 0 to 100 with a random uniform simulation. All the vents are set to closed, the compressors and the blowers are set to run at the median value where they typically run, and then we can simulate it to a data table and fit those to curves. Then we would go do the next valve and set this one to manual.
You can see we generate some curves. Now, they're not perfect. The model is not perfectly accurate. There's noise in the system, and so I wouldn't expect them to be perfect. But you can see it's certainly better than drawing a straight line across. We have more knowledge now than we did before on the change in flow with the change in travel of the valve. There's bumps, there's not perfect fits, but it's better than nothing, and it does help us improve the control of the system.
Now, I will show this actual work in JMP. You can see this is our data table. There's a lot of rows, a lot of data, a lot of historic data. We can look at that, and I'll go right to the model here. This is the neural net model we worked with. A couple things to point out here. Again, extrapolation control is on. If I'm going to do the simulator, I set this. I can choose fixed, random, expression, or multivariate. In this case, I chose random, and I chose uniform so I could run it all the way from the lower limit is 2.3 because we never actually ran it 0 with extrapolation control on, up to 100. I set my vents where I want them to be using these variables here to fix things where they need to be.
We're going to conduct an experiment. In simulator, I would, excuse me, simply go make a data table. Then it makes a new data table. The only thing moving in this data table is the valve 2 output and the discharge flow meter. From that, I can fit a curve. That gives me a numerical representation of the change in flow with the change in travel. That information can then be taken back and improve the control system.
Then we would simply do the same thing for the next valve. We'd set this to fixed, and we'd go find the recycle valve, random, and we're going to use uniform, and we'll run it from 0 to 100. Do the same thing, export to a table, and then fit the valve. Now, there's a few things I need to point out here. One is that within the simulator in JMP, it does offer the opportunity to do a simulation experiment. However, it's a space-filling design, and so it's going to move variables at the same time. Ironically, even though we normally say we never want to do this, we are truly looking for a one-factor-at-a-time experiment with this problem.
We want to move one valve and keep the rest of the system steady just so we can try to identify the change in flow with that one valve. This doesn't function. If there was a one-factor-at-a-time option here, that would work. It's also very similar to what happens when you do Assess Variable Importance, where you're resampling. But it's uniquely different for a couple reasons. One, we're adamant that we only want to do this simulation when all these vents are closed and the blowers are set just as we want them, etc, so we don't want to allow... We don't want to resample our data table. We only want to run at times when the conditions are exactly how we want. That's a little different.
The other thing that happens with this Assess Variable Importance is that you can get these marginal model plots, but you don't actually get formulas to transfer those into real numerical data that we could pull out. That's why a lot of people might be thinking it's very similar to what's happening there, and it is similar, but it's not exactly what we need. We're truly trying to do a one-factor-at-a-time experiment.
The other callout I would make, and we made this simple for the presentation so it could be an easy-level JMP display, but something you have to be aware of, instead of just using extrapolation control, you have to be cognizant of the fact that when you're simulating one valve and not moving anything else, it's possible you're simulating in spaces that are not within the operating plane of the system. For instance, there's probably not really a situation where this valve, the inlet valve of the system, could be completely closed almost, and we're running all three of those discharge compressors. There's just not enough gas flowing through.
In a real scenario, you need some way to ensure that you're only simulating across spaces that can possibly exist. One way that that could be done is with a multivariate model. If I were to build a PCA of this as well and then save that T² value out, put both of these predictions into the profiler and then simulate there and have that T² simulate, I could filter in my resulting data table for T²s that are below the limit and then ensure that I'm within the space, or I could use a PLS model.
There are certainly ways to handle that, and that's a higher-level topic that I wanted to not get into details here, but it is something to be aware of that you don't want to do a one-factor-at-a-time experiment where you could get yourself into non-operational spaces. Just a warning there.
Let's see, coming back to our... As we wrap this up, I think the innovation here isn't really in the JMP technique. It's really fairly simple on model building and profiler and simulation usage. The value in it and the unique use case is that an engineer has the ability to test their system and try things not online in the system. That's a problem that a lot of engineers run into is that there's an inability to try things out and learn because you risk taking a plant down.
Understanding that you could build a model off historic data, similar to almost a digital twin for analytical data, and then use the simulation tool within JMP to conduct experiments is really powerful. I think that's what we wanted to share here is that using that idea, you could conduct all types of experiments. It doesn't have to be valve characterization.
It could be what-if analyses, what if we increase the flow this way, what's going to happen? As long as that has happened before in history, you should be able to see a response in your profiler simulation showing you the results. Powerful tool, and once that model is built, you can conduct all the experiments you need on that system and learn from it. It's a useful tool for engineers.
I'd like to thank Scott Harmeier for this, and Mike Lindley, who's the co-author here today, and then Bill MacNy as well, who all played a role in helping to conduct this project. Thank you.
Presenters
Skill level
- Beginner
- Intermediate
- Advanced