PLC Recipes and SCADA

I was recently reading a thread here that talked about Ignition and PLC recipes. The thread dealt with the mechanics of getting the data from Ignition to the PLC. It got me wondering about a different aspect of SCADA/PLC interaction.

I am used to equipment having a local library of recipes in the controller. These controllers are older and were meant to be stand-alone, although the do have comms for monitoring by a SCADA system. At some point, I will be replacing the controls with something more modern, likely a custom programmed PLC. As I was reading the thread, it sounded like the situations mentioned referred to a PLC that only had 'one' recipe, the active one. It sounded like the library function was provided by the SCADA system itself instead of there being a selection of recipes in each PLC.

Is this a common arrangement these days? I suppose there are use cases for both situations, but having only one recipe in the PLC would seem to make the PLC programming aspect easier as well as SCADA editing of recipes. Is there much concern for the SCADA system going down? This would seem to leave an otherwise useful piece of equipment with only the current recipe available. Or are most peoples' SCADA systems reliable enough that this is a non-issue?

This is one of those times that I wonder if my limited perspective is skewing my planning process. In my little world, SCADA is something that was added on to the system to help monitor the equipment. Each piece is still fully usable without the SCADA system. The operators use it mostly to monitor what is happening without having to walk around to each item. They also will change a setpoint on a controller remotely, but they are just as likely to change it at the controller itself. The data logs and trends are helpful in diagnostics. Overall, though, the plant would continue to operate if the SCADA system went down.

I'm starting to think that modern SCADA systems are far more integrated with the plant equipment. It's possible that we will head down that road in the future, but I thought it might be interesting to hear how others are currently using SCADA systems.

Most of the older control systems in my plant are set up as you stated, that being that the recipes are SCADA controlled and only the ACTIVE recipe is in the controller. I prefer to keep everything in the PLC, mainly because of the problem with the computer running the SCADA going down. I believe a lot of the older systems were SCADA controlled because of the memory required to keep all of that data in the PLC. That is no longer the case as the newer PLC's do not have this restriction. As we upgraded our systems, the recipes are stored in the PLC's and can be accessed by any HMI. They are also all networked so we can easily backup recipes or transfer them to other systems.

I was one who posted in the thread you are referring to, and I think we need to establish the context of was a "recipe" is among systems. For simplicity, let's say you could have two different types of recipes.

1 - "Machine" Recipe
2 - "Process" Recipe (batch recipe).

We'll define those:
"Machine" Recipe - Recipe library in the PLC, machine can still operate if the SCADA portion goes down < 100 parameters.

"Process" Recipe - Recipe library at the SCADA level, in a database. Think of a large integrated process system. If SCADA is down, the operators can't interact with the process and control resulting in a plant downtime situation anyway. You can't continue the process just because PLCs are online, operations needs SCADA to monitor/adjust/test/quality check everything.

The project I'm working on, is a "Process" recipe. It contains over 900 different settings for the entire process. This single recipe, covers parameters for 10 different pieces of equipment. It's critical to the end user that they only manage a single recipe, but the recipe must cover the entire process of making their product. It is also important that there is no limit to the number of recipes they can create so they can make whatever concoction of an end product they wish without having to call us. It also must be considered that track/trace features may be implemented in the future, as well as recipe versioning and tracking. So it's important to track Lot codes, campaigns, recipe creators, creation dates, version number...etc.

You simply can't achieve this trying to store everything to a PLC.

In this setup, the recipe values for the active process are downloaded. But all the "meta" data of the recipe are not, that remains in the database. Only the control points required by the PLC are sent from the database to the PLC. If SCADA went down, the current recipe parameters are still active and the PLC and still do it's thing up until the point where an operator needs to interact with it. Say, an acknowledgement that a manual addition has been completed by the operator. Or when the next process needs to run and a recipe download needs to be triggered.

With this setup, I can now link recipe information with production run data and create detailed reports of what is happening in the process. Much easier to do this type of design work at a database/SCADA level than mixing data from a database and recipe libraries stored in the PLC.

Each has their place, but once you get beyond basic machine parameters recipe storage at a database level is essential.

Thanks for the thoughts guys.

Paully, I wondered if you had a complex, interconnected process when I read the original thread.