I am accustomed to measuring the expertise growth in any domain of engineering not entirely by the deepness of knowledge acquired, but by the change in the priorities list. One of the indications of process engineer maturity is knowing her/his customers - control and instrumentation engineers - and the interface separating both sides - Process Control Narrative.

Process Control Narrative (PCN) aggregates the information needed by the control systems engineer to begin control design. PCN is challenge number two in mega-projects after the procurement for the following reasons.

PCN describes how the process shall be operated and controlled. Descriptions are problematic; they represent the generic process knowledge intermixed with specific P&ID tags.

  1. Tags make the description copy-paste impossible
  2. Tags are not hyperlinked to P&ID, search for the tag location overshadows the task of understanding the process nuts and bolts
  3. Inserting tags into text is error-prone
  4. Tags' synchronization with other documents trumps desire for better writing

PCN is a multicolored patchwork - a collection of information pieces copy-pasted from disparate documents: the list of equipment and instruments, interlocks and alarms, control loops, power consumers, etc. Any update in a source document shall be manually copied to PCN. Late updates are a norm.

PCN targets not only control engineers but the plant operator as well; it shall contain plain instructions for the subsystems' operation. In this case, PCN is an information source for O&M manuals. With the plant operator being the final reviewer and approver of PRN, its quality standards shall rise.

To prepare good-quality PCN, the process engineer shall be skilled in technical writing and control safety design – things beyond the engineer assignments.

PCN workload is often disregarded in the project schedule even though it is comparable with that of control design - 1 hour per each I/O. PCN triples the process engineering workload. Thousands of work hours discovered at the end of the project contribute immeasurably to the project handover delay.

PCN is the most referenced document; it is a basis for operations practices review and alarm rationalization over the entire plant lifecycle.

PCN template & minimum vital version

The template objective is to get PCN rid of assumptions and implications and make PCN more concise. PCN template not only defines the typical scope but also the sequence and format of information pieces for every subsystem of the plant. Subsystem identification is discussed in the "Project Quality and Alarm Management" article. The subsystem PCN shall cover the following points.

  1. Subsystem purpose & classification (main, auxiliary, batch, etc.)
  2. Modes of operation (ex. duty, cleaning, overload)
  3. Definition of normal operation states for each mode
  4. Definition of test & maintenance states
  5. Preconditions for normal operation (subsystems interaction)
  6. Abnormal operation
  7. Reliability requirements and control & monitoring redundancy
  8. Alarms and safety interlocks (linked to troubleshooting)
  9. Level of automation required
  10. Control purpose and implementation
  11. Normal and emergency start/stop sequences
  12. Data acquisition adequacy
  13. Data management and reporting
  14. HMI requirements

This list is a collection of fundamental categories of engineering thinking. it explains why PCN is sometimes called Control Philosophy to emphasize the value of deep inter-disciplinary expertise.

The huge scope of PCN in mega-projects and lack of expertise in personnel training is one of the reasons why desalination companies favor BOO (Build-Own-Operate) contracts.

In practice PCN is considered a supplement of P&ID; it is prepared after the long-lead equipment sizing and quotation requests. The wrong execution sequence triggers revisions flooding.

Being regarded as second in importance by engineering companies, PCN is substituted with a minimum vital version (MVV). It includes the following information pieces.

  1. P&ID excerpt with tags
  2. Equipment list
  3. Instrument list
  4. Measured value set points and ranges
  5. Control loops list
  6. Operation modes
  7. Operation statuses for each mode
  8. Valve matrix covering modes and statuses
  9. Normal start sequence (what-if scenarios disregarded)
  10. Alarms and interlocks list
  11. Data exchange in subsystems' hierarchy
  12. Decision-making distribution in subsystems' hierarchy
  13. HMI sketches and graphics symbols list
  14. HMI instructions and messages database

Even this MVV requires thousands of work hours due to ambiguities and discrepancies visible only to the control engineer during SCADA coding.

Crenger changes the rules of the game; it makes PCN the starting point of the project engineering. Strong evidence of this is the P&ID graphic standards; they comply with HMI requirements!

Introduced by Crenger continuous data validation blocks the engineering progress if any of the PCN parts is not implemented. Crenger auto-compiles MVV documents at the user's request. Samples may be found on the website.

Restoring PCN in full scope is the next target set by crenger.com as the bitterness of the PCN's poor quality remains long after the sweetness of the MVV low price is forgotten.

© 2024 crenger.com