S88 and Continuous plants

S88 Batch procedures carry out an ordered set of process operations on a finite quantity of stuff, batch by batch.

This ordered set is called by Part 1 a Recipe Procedure. It can be represented as a sequence of operations in time, typically by PFC/SFC logic .

A sequence of operations may take place in one place (or Unit) or different stages may take place in different units.

Note – this implies transfers, which S88 carefully does not attempt to explain.

Continuous production also carries out an ordered set of process operations, however the quantity of stuff is not finite, instead it grows in time, and more than that, most operations take place in Units that are specific for the operation, the chemistry happening as material flows through the unit.

Thus, the recipe procedure for a continuous process may well be represented as a process flow sheet - without the need for a PFC. And, actually the transfers are then implicitly described.

By the way, yes, PFC’s or SFC’s may be a good way to describe startup and shutdown and grade changes, that does not mean they are Recipe Procedures!

I have before suggested that Part 1 needs what I call a recipe equipment entity model, to underly the equipment requirements that are part of the (master) recipe.

I also suggest that the recipe equipment requirements are best described by a process flow sheet. This works with both batch and continuous.

The recipe view of the equipment should be generic, in terms of types of equipment, whereas the physical model must contain one or more of each of the types required by the recipe.

Where I seem to disagree with the work being done to “improve” Part 1 though (and this is compounded by the emerging Part 5) is that the procedural model is not a good model for actually controlling equipment. I think that State Based Control (check the tags on this blog) is a good example, it simply does not fit conventional S88.

There are ways in which Continuous process can be made to look like batch ones from the scheduling point of view, or even the broader point of view of an ERP or MES

In fact it is quite easy.

ControlGlobal's Process Automation Usability Project

Recently ControlGlobal.com has created the Process Automation Usability Project, it is an interesting read, with ongoing discussions on Planning, Design, Implementation, Operations, Maintenance, and Security.

It is well worth reading or better still taking part in, so I have added it to the Automation Links on this blog.

Part 1 update - what has changed

Marcus Tennant has produced an excellent summary of the changes between the latest draft of the updated S88 Part 1 standard and the original.

It must have taken him a lot of time and I have no problem with it.

I do however have a problem with the proposed update itself.

Here is a small example, it shows the proposed changes to the physical model.

Now as far as I am comcerned, the original version, on the left, is elegant and clear whilst the update is frankly a mess.

And the value added is zero.

How do standards evolve?

I was thinking again about the S88 standard and how it is developing, and the results that we are seeing. That led me to wonder, how do standards evolve?

So I thought that some research was needed. And I have searched a lot, and one noticeable thing about the results on various search engines is the association of standards with law.

Things like metric and imperial, Whitworth and so on are measurement systems and physical and science based. Even if they started with the distance between Napoleon's nose and his finger tip, allegedly. And so De facto standards arrived. Eventually they became consistent, via such thing as the System International (Three nations have not officially adopted the International System of Units as their primary or sole system of measurement: Liberia, Burma and the United States.)

Others like ASCII and perhaps html are language interpretations.

What about Fieldbus or, say Betamax versus VHS ?

Here, competitive companies produced competing standards, and the result became De facto standard.

Some such as XML, maybe UML are somewhere between De Facto and Science based - or at least they involve a lot of meetings.

When we come to Automation is it apparent that the ISA (For me still the Instrument Society of America) that now appears to be the leader in setting the standard.

But I actually think that it is missing the competitive element. I could argue that they should leave the domain alone until a De facto standard arrives!

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.