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).

 

Well the modern approach is that taken by Virginal Galactic and leave it up to the programmer....

This leaves quite a disconnect between the process hydrodynamics and can lead to a costly mess with equipment failures, multiweek shutdowns and impact on the bottom line.

In man-safe applications the process control logic needs to be documented in detail and subject to engineering, maintenance, operational reviews...

In those cases, even for a single p&id you can have a 100 C-sized sheets of control logics. You can imagine the management response of most firms...

Of course the beauty of leaving the control description to a process control narrative is that you pass the liability to the next guy and ultimately to the operating/maintenance staff...that pleases most

Good luck

 

I have used the following as a summary of the information required in a control system narrative or description. This is an extract from some notes I prepared a few years ago.

"THE CONTROL LOOP DESCRIPTION -
The Control Loop Description is a brief document summarising the details of a control or measurement loop, and the components in it. It provides a means of recording at the design stage the decisions taken, and the reasons for those decisions, that will influence the final loop. While the Control Loop Description is primarily of use for control loops, it also can be used in a simplified form for measurement systems.

Adjustment and tuning of control loops during commissioning requires an understanding of the purpose of the loop. For instance, a level loop may be installed primarily to provide a constant head and must therefore give accurate level control over a range of flows, or used to maintain a level within broad limits for storage purposes in a situation where steady flows are the primary requirement. The two applications will be set up in different ways. Loop configuration also will depend on the likely sources of disturbance, and the magnitude and dynamics of disturbances, so the Control Loop Description should record this information at the design stage for later reference. It also prompts the designer to take operational and maintenance requirements into account. Suggested headings are:

FUNCTION
[Specify the vessel or flow stream monitored, and state why the loop is installed.]

CONTROLLER MODES AVAILABLE
[State whether the loop must be made available for Auto, Cascade, Manual, etc. operation]

CONTROLLER ALGORITHM
[For P+I types - details of settings
For calculations - details of the equations

LOOP DESCRIPTION
[Identify the process stream in more detail, with any peculiarities of material etc. Type of transmitter, and any special signal conditioning should be stated. Where a complex control algorithm is to be implemented, the Functional Specification for the control should also be defined here. Details of final control elements and their behaviour.]

ALARM FUNCTIONS
[Specify alarm settings, and give a brief justification for having the alarm.]

OPERATOR INFORMATION
[List all information pertinent to the operation of the loop. This should include details of lining out procedures for control loops, and the significance of and recommended operator actions in the event of an alarm.]

COMPONENTS
[List each component used, its function, and input and output ranges where appropriate. This provides a useful check that all components have compatible ranges.]

MAINTENANCE
[Specify the precautions needed to allow maintenance on the loop - to include isolation and other actions. This should include any design features required to allow maintenance. Special consideration must be given to the effects of isolation on other related systems.]

OTHER ITEMS
[Specify any other points that could affect loop operation - e.g. ramping. Also identify any situations where the normal behaviour of this loop is interrupted, or affected by another loop.]"

You are quite right when you say that a PCN or PCD may end up setting out what is the expected behaviour when things are going to design - when a control system by its nature is only needed if things go off-spec or behaviour goes outside permitted limits. I have found that a good tool for sorting this out (and for highlighting the issues ) is a Sequential Function Chart or Flow Chart constructed so that every decision is an IF-THEN-ELSE construct, rather than WAIT UNTIL or WHILE - for example, if a starting sequence calls for fuel to be injected when speed reaches 33 %, there needs to be a time limit set so that the logic reads
IF (speed > 33 %) & (time > 45 seconds) THEN (*add fuel) ELSE TRIP.

In other words, for each stage, identify reasonably likely causes of failure and make sure it's dealt to. Be warned - you will get into endless arguments about what is "reasonably likely" - Mr Murphy has an endless supply of ways to make things go wrong!

 

The Implementation of SAMA diagrams helps one to identify the scenario in which one type of control is activated or stopped.

It is normally developed as a communication method for non-programmers (Flow chart like sequencing). But yes the reader needs to have some knowledge of the system being discussed.

Fail scenarios are discussed is a section called SIS - 'Safety Integrated Systems' for the plant. This discusses the 'Fail Safe' control for the Plant. (Meaning the status the plant should be if a fail occurs, without catastrophic effects). The plant will have Instrument controls design specification known as SIL. The greater the number of SIL, more safer the system will be.

These are the reports normally a Manager of Plants look upon to understand the whole system without having to go too much into programming details.

I hope that's what you're looking for.