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.

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.