R
I have an open ended question about P&IDs and Process Control Narratives (PCNs).
Our organization has been using P&IDs for a long time. (We also used to use loop diagrams until it didn't make as much sense to use loop diagrams since with the advent of DCS systems and PLCs, the field instrumentation and devices get connected to the DCS or PLC and the DCS or PLC becomes a large "black box"). The P&ID conventions adhere fairly closely to ISA-5.1, insofar as they show what is connected to what (and where) within our processes. Yet, when someone is looking at a P&ID drawing, one is left to really guess as to how the control is actually done inside the DCS or PLC.
With the advent of computers and PLCs, we used Process Control Narratives (PCNs) to describe in written form what kind of control is to take place. The primary author of the PCN was to be the engineer, who in our organization would usually leave the programming up to someone else (such as a systems integrator - the engineer verifies during commissioning). The PCN was to be the "blueprint" that the programmer was to follow. Unfortunately, these PCNs often end up only telling the programmer how a process is to function when everything is working well. Any of you who have done process programming know that writing a program to do what you want when everything is "normal" is only part of what really needs to be done in a program. Good programs protect people, processes and equipment from disaster when things go wrong within a system (faulty sensor or field device, unforeseen sequence of events, loss of power, return from loss of power, etc). It is much harder to convey ideas within a PCN or P&ID for how a system should operate when things aren't "normal". Also with PCNs, I am reminded of what a Hamline University professor said once in a technical writing course he taught in our organization ("There is nothing written anywhere by anyone that can't be misinterpreted somewhere by someone." - F. Garvin Davenport).
What methods and tools have you used within your organization to convey ideas for how a process is to operate (in good times and in bad times)? Remember that your audience might be someone who is not trained in control engineering, yet has a need to know . . . or perhaps has a good idea . . . about how the process should operate (this person could be an operator, maintenance personnel, or plant manager).
Our organization has been using P&IDs for a long time. (We also used to use loop diagrams until it didn't make as much sense to use loop diagrams since with the advent of DCS systems and PLCs, the field instrumentation and devices get connected to the DCS or PLC and the DCS or PLC becomes a large "black box"). The P&ID conventions adhere fairly closely to ISA-5.1, insofar as they show what is connected to what (and where) within our processes. Yet, when someone is looking at a P&ID drawing, one is left to really guess as to how the control is actually done inside the DCS or PLC.
With the advent of computers and PLCs, we used Process Control Narratives (PCNs) to describe in written form what kind of control is to take place. The primary author of the PCN was to be the engineer, who in our organization would usually leave the programming up to someone else (such as a systems integrator - the engineer verifies during commissioning). The PCN was to be the "blueprint" that the programmer was to follow. Unfortunately, these PCNs often end up only telling the programmer how a process is to function when everything is working well. Any of you who have done process programming know that writing a program to do what you want when everything is "normal" is only part of what really needs to be done in a program. Good programs protect people, processes and equipment from disaster when things go wrong within a system (faulty sensor or field device, unforeseen sequence of events, loss of power, return from loss of power, etc). It is much harder to convey ideas within a PCN or P&ID for how a system should operate when things aren't "normal". Also with PCNs, I am reminded of what a Hamline University professor said once in a technical writing course he taught in our organization ("There is nothing written anywhere by anyone that can't be misinterpreted somewhere by someone." - F. Garvin Davenport).
What methods and tools have you used within your organization to convey ideas for how a process is to operate (in good times and in bad times)? Remember that your audience might be someone who is not trained in control engineering, yet has a need to know . . . or perhaps has a good idea . . . about how the process should operate (this person could be an operator, maintenance personnel, or plant manager).