Loop and Logic Diagrams and P&ID’s

This has recently been discussed at length on LinkedIn  on the ISA – International Society of Automation group under the title "Does control logic belong on P&IDs?"

Among the comments are
....Adding logic functions to a P&ID clutters it, is prone to add further unnecessary revisions to the P&ID every time a logic is changed ...
...agree that the complexity that we can configure into the DCS, PLc, and SIS cannot be represented adequately on the P&IDs...
...No, detail logic does not belong to PIDs. A PID is a construction document, as such it must show:
1-Hardwired input to logic interlock, complex loop or DCS/SIS
2-Hardwired output from logic interlock, complex loop or DCS/SIS to Final Control Element FCE
3-Identification of logic interlock, complex loop or DCS/SIS. Separate documents are generated for interlocks and complex loops...

So, how much can reasonably be shown on the P&ID depends on the type of process and previous practise but at the end of the day there are nearly always extra diagrams, typically with a cross reference on the P&ID. This blog post provides an explanation of how you can use ControlDraw to draw all those extra diagrams and relate them to the P&ID's
Top level diagram contains an object for each P&ID and child pages then provide a graphical list of the relevant loop and logic diagrams which are then diagrams under each object.
Here is a diagram that explains this (click to see full size)

This can even be extended to cover such things as State based control Matrices and Cause and Effect Matrices
Note - if you have a list of the P&ID's (which is normal) you can copy the list to create the P&ID Overview diagrams using Paste Special as Rows. And you can create all the P&ID Overview diagrams with a couple of clicks from the Group Menu >Create/Link Child diagrams.

Programming Equipment States Efficiently

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. ControlDraw has long supported this method as it provides a very efficient method of representing functional requirements. An Equipment State Matrix can show the required states of all the modules in the Equipment entity, for example:

When it comes to programming this in a Process Control System it is possible to make highly efficient and fast code by deploying the State Matrix as a data table, with the phase steps simply setting a index into the matrix. This really is far more efficient than having each step in a sequence contain all the required device settings and it becomes more efficient the more states and steps there are. The software diagram below shows how this might be done.

So, to help PLC/DCS programmers with this, the latest version of ControlDraw has added a function to generate the data table in a form that is compact and can be easily entered into a PLC or similar. It compacts all the values in the rows into as small a memory block as possible.
(Note - if PCS's had a language that supported such multi-dimensional arrays this would not be needed, however that is not something that I have in practise seen.)

View > Matrix Data Table >Matrix as Boolean for example generates the following text that you can copy to the clipboard:
Row Bool Name
0 00100 'Shutdown
1 00001 'Ready
2 01100 'Fast Fill
3 10100 'Slow Fill
4 00000 'Mix
5 00110 'Transfer
---- Mapping:
Bits required = 5
Bits 0 to 1 set EM02
Bit 2 sets em Fixed Speed Agitator
Bits 3 to 4 set em Feed

You can also generate the table as integers, hex or octal

Note - this is now part of the standard S88 Reference model library that comes with ControlDraw

State Based Control

There is a new White Paper on ControlGlobal.com called "The Benefits of State Based Control" written by David A. Huffman from ABB

Walt Boyes calls it a "very important white paper". It is quite good and I recommend readers, specially those working in the Continuous process industries, to download it. You have to register with ControlGlobal to get it, but that is worth doing anyway.

The paper does not claim that SBC is new, and indeed it is not. In fact SBC - or something very similar, has been the basis for a lot of ControlDraw models since CD was first introduced, in the mid 90's, and that itself was based on previous paper based ways of specifying State Based Control.

And in turn these models were often then implemented using SBC, and on a variety of systems.

The paper also suggest that implementing SBC is something that ABB with it's 800ax system has removed barriers to. That may be so, but the paper is short on details. Interestingly one of the systems that CD models have been used to spcify (and frequently) is Sattline, now owned by ABB themselves. A little known fact is that 800ax is a direct descendant of Sattline, a system that can probably claim to have been the first object oriented DCS, it has been around since the 90's.