What's in a Process Cell

There is currently much discussion about what a Process Cell is as you can see on the Part 5 blog.

As I view it, a Process Cell:

1- is the domain within which batches can be made according to a recipe.

2- contains the collection of equipment (units, and equipment modules) that meet the equipment requirements of the recipes that can be produced in the cell

That is I believe what S88.01 says, but in different words:

S88 (original and latest draft) says

A logical grouping of equipment that includes the equipment required for production of one or more batches. It defines the span of logical control of one set of process equipment within an area.

NOTE - This term applies to both the physical equipment and the equipment entity.

But this really does not define the boundaries of a Cell in the way that we like to put boundaries around Units for example. Why not make an entire plant a process cell? Of course, a cell lives 'in an area' .

So might be that the boundaries of a Process Cell are arbitrary provided they meet the definition.

I have seen several large plants where there are dozens of Units in the Process Cells, and have worked on projects where there were only a few. Why? Because of repetition - if you have many similar units it makes sense to put them into the same process cell because they can run the same recipes. And Recipes execute in Process Cells.

But as Part 1 also says Logical Control

Is that Logical as in mathematics? Or as in intuition?

From the Intuition point of view, it just makes sense to have say solvents handing in a different process cell to reaction doesn't it? Is that enough?

But how about Logical Control? Are we talking about basic control logic - or Procedural Logic?

I think we can forget basic control here so can we somehow make a logical choice based on the Recipes? And one that generally agrees with the intuitive one? I think so.

It depends on finding the Batches, Equipment Requirements and the Routes.

Start by asking where are the batches? If a batch comes out of one unit, and then joins with other batches so that the downstream units are working with bigger batches, or conversely where batches are split up so the downstream units are working on smaller batches then I would have two process cells. In the case of say a plant with feed storage vessels then bioreactor units then intermediate storage then filtration units then product storage I would have something like Feed storage process cell bioreactor process cell intermediate storage process cell filtration process cell product storage process cell And by the way I would call the storage vessels Units.

As for the connectivity, what I mean is that all the euipment in a single Process Cell should permit the transfer connections needed to assemble the instances of required equipment for the Cell's Recipes.

AutomationML and ISA88 Part 5

According to Wikipedia, AutomationML (Automation Markup Language) is a neutral data format based onXML for the storage and exchange of plant engineering information, which is provided as open standard. Goal of AutomationML is to interconnect the heterogeneous tool landscape of modern engineering tools in their different disciplines, e.g. mechanical plant engineering, electrical design, HMI development, PLC, robot control.

Now, this looks to me to be covering much of the same areas as ISA88 Part 5 is attempting to deal with, in fact possible more. I suggest that the people involved in Part 5 should spend some time investigating AutomationML.

AutomationML is clearly coming from the European side of the pond (ok mostly Germany), whereas Part 5 is largely from the USA side.

I would really like to see something that explains how they relate to each other and whether there are synergies or indeed if they are competing.

DCS or PLC and Systems Integrators

As I mentioned in the last posting, there can be further reasons why a DCS solution may be better, for example the maintenance of the PLC/SCADA systems may be more involved because they all have different software architectural designs, no two SI's seem to do it the same.

Or the long term viability of an SI - and they are vulnerable - puts a client off compared with the stability of the DCS suppliers.

How can the SI's overcome these issues? At present they largely compete with each other.

What if all the SI's in the CSIA shared their designs?

and used identical documention systems?

and even shared their module libraries?

Then it would be easy for projects to be handed over to another SI if needed.

I think this would help the PLC/SCADA suppliers as a whole to compete with the large DCS suppliers, it could even put them at an advantage over the DCS suppliers.

Is this feasible?

I think it certainly is regarding the documentation systems - and I don't mean word processing, but by using object models, perhaps according to ISA S88 Part 5 - or of course ControlDraw models.

Now, the CSIA has developed some standards, such as CSIA’s “Best Practices & Benchmarks” Revision 3.0.1. This is an excellent document for both end users who want guidelines on selecting an SI and for SI's themselves to review their own business processes. But it is not a standard design.

And by the way, the CSIA is predominately American, few European SI's belong to it, so if you are looking for non US suppliers you need to look elsewhere. Your local PLC suppliers such as Rockwell, Siemens etc will be able to suggest a few.

DCS or PLC?

This is a topic that has been discussed endlessly over the years ever since there were DCS’s and PLC’s with SCADA on top.

Back in November I noted a great article, do PLCs Eliminate Need for a DCS? on Automation.com that sums up the differences well. It does so from the point of view of the pro DCS Camp, not surprisingly because it is essentially a Honeywell interview.

Refreshingly though, it does not promote Honeywell over other DCS’s and just presents many of the core arguments that all DCS suppliers present. They are well presented good points

DCS's have succeeded for a good reason. They were the first to encapsulate things like PID control, and emulations of control panels. And the PLC people encapsulated relays and won the discrete market.

It would be good to see the other side of the argument presented equally impartially, no one has done so in response to that article, so I am having a little go. It may be because the suppliers of PLC/SCADA systems are more numerous but smaller, and none has the time to present the argument. Perhaps this is something the CSIA (Control Systems Integrators Association) should address.

So, lets looks at the core issues
"Today with open technologies, DCS systems are competitively priced with PLCs."
Maybe – but it is not my experience for the Hardware. This may well be true if the engineering is less, but that is another topic – the next one.

"Simply taking a PLC and adding an HMI and database on top of it requires a great deal more engineering to accomplish integrated control..."
I am one of those who has in the past been responsible for such engineering, and I don't quite agree with the term 'more engineering'. Better maybe, more is dependant on the application. Sure DCS’s are still far and away easiest for plants that have control loops and little else, such as refineries and the continuous chemical industries. And you would never use a DCS controller for fast machine control.
But it is that huge area in-between that the paper suggests is now DCS territory. But there are many case where PLC/SCADA still prevails. The food and beverage industries such as brewing and diaries are good examples.

And I am well aware of projects in the past where the engineering has taken far more that expected, even where a DCS was being used.

Why is configuration better than programming?
First it is highly a debatable point. Much of a SCADA is configured rather than programmed, and no configuration system exists in DCS's for complex sequential control for example.

Also, programming is not actually a bad thing, provided they are designed well, systems with programmed rather than configured applications can be better. This is because there is much more flexibility of design resulting in much less compromising of the functional requirements to fit the standard system.

Other points include:

Future growth

This is disputable as probably the largest (by IO Count) systems in the world are PLC based.

For example many food manufacturers have huge systems.

Need to make changes frequently

Of course if the application is well engineered such changes should be rare. New recipes should not require program changes for example

Integration requirements

Again, at least in the past it has long been easier to interface to other systems.

Even now DCS interfaces are often implemented with ModBus, and where did that start? PLC's!

Fault Tolerance

I think PLC's may have caught up here

The PLC vendors still seem to be struggling with trying to get all the parts and pieces to work together seamlessly.

Really? This may be true from the point of view of a small PLC/SCADA Systems Integrator competing with a large DCS supplier to win a project. But I think this is not a technical issue, rather one of the nature of those two types of supplier

I am convinced that the results using a well designed PLC/SCADA can be far better than using DCS canned functions. Not only in the result, but in the time it takes to write the software, the user interface, the scan time for the program to execute, and the hardware cost.

I could add further reasons that a DCS may be better, for example the maintenance of the PLC/SCADA systems may be more involved as they all have different software architectural designs, no two SI's seem to do it the same. But I will cover that in another blog soon

Automation objects and State Based Control

State based control is a method of defining the required states of some equipment and then driving the equipment to one of these states, typically where a Phase step sets the Equipment States.
It is an excellent way of describing the required behaviour of an Automation Object, or at least what I think of as an automation object. But I cannot relate it to Part 5 as it stands.
In essence designing a state controlled automation object involves in a large part determining all the required states that you need to set that object to. Please note that these States are not comparable to the Part 1 or 5 'Procedural States', they are things like Open, Closed, Ready to Fill, Filling, Reacting etc.
ControlDraw has long supported this method because it provides a very efficient method of representing functional requirements. And consequently over the 10+ years of designing systems with ControlDraw I now have designs for hundreds of these. You can read more here and here.
They range from basic control modules like motors and valves to highly intricate units, such as BioReactors, semi continuous sterilizers etc.
And looking at these, they have never needed to contain Resource Management. Yes they may have properties that relate to Resource Management, but always the actual Resource Manager is outside them. The lower level ones such as PID Controllers, are contained in Equipment Modules or Units, and the Resource Manager does not look at them, it only deals with the higher levels.
This is one reason for my objections to Part 5 as it stands. But please understand that I don't want to spend my time complaining about Part 5, I want to contribute positively.  

As it stands, I cannot. I think it should be completely re-started or abandoned.

Equipment Modules or Control Modules, which are cheaper?

I heard a good one today. I had emailed the State Based Control paper to a customer asking why parts of their plant model did not have Equipment Modules, perhaps on the lines of those in the SBC paper. I got a very good answer, part of which was that all the operational aspects in those areas are manual SOP guided. And that maybe some procedural control will be added when they understand better how to run the equipment.

But another aspect was that they get charged more for more equipment modules.

Now, I have been looking into the complexity of systems, and hence the time it should take to program them. And part of the point of using Em's is to reduce complexity.
So I suggested that as they do not have to run phases ( just like those in the SBC paper) call them Control Modules!

More on State Based Control

I spent a lot more time going through the ABB paper on the benefits of State Based Control

And in order to understand it better I have spent some time turning their example into a ControlDraw model. It was very interesting, first finding how easily the example can be modelled (using standard ControlDraw features such as Equipment State Matrices)  and how similar the ABB/Dow method is to the way ControlDraw can handle such requirements. One example (of many)  is that ControlDraw supports what you might call cascaded State matrices, where the state in a higher level matrix (for example a Unit State) sets the state in a lower level one such as an Equipment State. 

Please note - I do not mean the states like Starting, Holding etc in S88 Parts 1 and 5, I mean states like the ones the paper uses like Total Reflux, Empty etc. Well done ABB.

I also looked at some models in my archive where I found examples of Units that have 50 or more states and 20 or so equipment modules as compared with the 9 states and 6 EM's in the paper. Some of these date from 2001. So it really is not new. But nonetheless it is good approach, and as my examples show it is also highly scalable.

The paper says

"One last benefit of SBC is that it is an implementation of process control based on the principles outlined in ISA S88 Part 5"

I cannot see that at all. If anything the paper presents something better than Part 5 has offered, but it is really quite unrelated. I cannot either find any indication that ABB has been involved in Part 5 - I may be wrong, but if I am right, please ABB get involved, and don't make such statements for the sake it of it. 

One negative - a detailed review showed how poor the spreadsheet examples in the paper are.

The problem with using spreadsheets for this kind of application are numerous. Typical problems include:

1. Complex formatting, which while it may make table look pretty actually makes it very difficult to extract the data, for example to help with generating the application.
   
2. Multiple lines in the same cell are often a problem
3. If a tagname changes then there is a lot of work to correct the spreadsheet
4. You need a spreadsheet for each Unit, and there is nothing to handle higher levels like process cells

Of course these problems disappear if you use ControlDraw !

By the way, the same paper is now available from Automation.com, and you do not have to register.