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

S88 Control System Designs

I think that it is a very good idea to use the S88 part 1 models as a framework for a batch (and indeed other) control systems. If you have a reasonable Control System design then it should be possible to use S88.01 Models and Terms to write a fairly precise description of the design.
That does not mean that S88.01 is a design for a control system. And that is clearly stated in the original standard.
Part 5 as it stands appears to be attempting to go into areas (such as a generic model for equipment and control modules) that are explicitly excluded in the introduction to Part 1.
Most worryingly the Part 5 fans are now trying to change Part 1 by introducing their models into Part 1. It is bad idea that would undermine the beauty of Part 1.
Now, Part 5 fans, please understand that I do realise that you may have some very good Control System designs (tho mine may be better) but that is not the point, Part 1 is not at all about designs for Control Systems.
If the objective is have a standard design for re-usable Control System Objects, then it should have a major input from the suppliers just as the development of FieldBus and the like has had.
They are notable by their absense from the Part 5 - where are ABB, Emerson, Yokagawa, Siemens etc. Mostly they are lurking - they are on the mailing lists but rarely take part.