Every mega-project I participated stumbled over the same point – instrumentation and control (I&C) design. Its budget and workload overruns affect the plant operation safety and reliability. Numerous I&C design patches is a norm for a long time after the plant commissioning.

How serious are they? HSE research, published in their book 'Out of Control', shows that 60% of all process industry accidents can be traced back to errors in the I&C design and specification.

The pressure of industrial IoT tsunami makes this pitfall even deeper.

From the plant owner perspective "I" in P&ID contributes most to the plant safety & reliability, efficiency, controllability & remote visibility. Definitely, "I" is more influential than "P" and should dominate in modern P&ID development.

Quality I&C design requires tremendous volume of information input from a process engineer. It is conventionally documented in Control Philosophy and Sequences of Operation (SOO).

This information is a superset of P&ID data. As it is teared off P&ID it lacks any visualization – unsurmountable obstacle for I&C engineers to digest and pack it into SCADA software. (Today, the term SCADA refers to the entire process automation and control system.) Paradoxically, its core part – HMI programming – is all about visualization.

The mentioned obstacle may be one of the reasons why over 70% of industrial IoT projects are stuck in piloting. 

Bridging the gap between P&ID and SCADA should start on the process side – by digitizing control, safety, and data acquisition requirements.

SCADA implements 2 types of the process controls – continuous and discrete-state (DS) ones. Over 90% of work-hours spent on I&C design is allocated to the latter.

DS control operates with states, transitions between states, and events. Its starting point is partitioning the plant into subsystems tree. Its leaf elements – P&ID instrumentation and drivers – eventually define the tree root – the plant states ranging from "collective fault" to "running".

It's worth mentioning that the plant hierarchy is a basis for HMI design, reliability prediction and even Hazard and Operability studies (HAZOP).

The bigger the plant, the more operating states and events are. For $US150 million desalination plant their count hits 12000!

Tremendous volume of work makes DS control challenge Number One.

Hence, P&ID shall provide interface for visualization & aggregation of P&ID items states and events, the plant subsystems states and hierarchy.

Unlike SCADA, this interface will have access to all P&ID database and use terms and language understandable by the process engineer. It makes the control data re-usable in future projects.

Transition between stable states is the essence of DS control. To program it, the I&C engineer shall understand the general descriptions given in SOO book and turn them into sequences of precise Boolean algebra conditions. They are at the core of PLC program.   

Why this trivial task – moving from control narratives to Boolean algebra - cannot be done by the process engineer, to import binary-state sequences (as structured text) directly into PLC program? And save thousands of workhours? She/he simply does not have any tools! So we come to the second point.

P&ID shall provide operation sequences visual editor. 

Continuous control poses no trouble as it requires substantially less information. Its major part - PID controller settings - stored in HMI program not accessible for the process engineer. It means that control experience cannot be learnt from or replicated in future projects. Conclusion is straightforward.

P&ID shall store the PID controller settings. 

Design for safety covers alarms, interlocks and failure sequences. By ANSI/ISA‐5.06.01-2007 alarms should define the process safe operation envelope and possible consequences and guiding steps if process goes awry. Why is the second part always missing from SOO? In my practice, SCADA does not store this information either.

P&ID shall include interface for alarms full specification – hazard levels, induced losses, prioritization, suppression, recovery mode, validity, and guiding sequences. It shall include auto-detection of instruments requiring redundancy, and the instrument service type – control, protection, and monitoring.

The same standard defines interlock as a single cause-and-effect link between initiating and control devices. This definition is not applicable to safety interlocks in the multi-hierarchy control systems - current standard for big water treatment plants.

For example, high pressure reverse osmosis unit includes at least 3 pumps. Any safety interlock shall shut down the pumps in the proper order to avoid equipment damage.

Such interlocks are compound in nature and very similar to failure sequences; their logic may include Boolean conditions and even other interlocks.

P&ID shall include user interface for simple, compound and sequential interlocks creation.

Mentioned alarms, interlocks, and redundant instruments are elements of basic design for safety. Its highest level can be achieved with implementation of Safety Instrumented System (SIS) approach.

Its functional and safety integrity requirements are usually determined from Design Safety and HAZOP, and P&ID reliability analysis (to determine SIL - Safety Integrity Level). It may use generic reliability data, for example, from OREDA or Crenger.com.

P&ID shall provide user interface for HAZOP and reliability analysis and SIL-marking of the plant hierarchy components.

The final set of requirements concern Data Acquisition (DA). Its scope keeps on expanding – industrial IoT being the powerful catalyst.

The primary question to DA is whether startup and shutdown sequences or batch processes are fully automatic as promised by the engineering services provider? Is DA adequate for the plant operation assessment, periodic testing, trend analysis, and reporting? Are MTBF values not forgotten to record? I guess, answers should be from the process side.

Functionally, DA deals with raw and converted signals (parameters), conversion formulas, and lookup tables. All these are rooted into P&ID instruments and part of the process engineer duties.

P&ID shall provide the user interface for the parameters, formulas and lookup tables editing and aggregation into bigger "chunks" – data streams and status report templates.

These requirements are already implemented in Crenger P&ID. In addition, it auto-generates SOO book template.

This video shows Crenger implementation of the editor for DS control states and sequences.

Maybe it's time to move in P&ID from "D" as Diagram to "D" as Database?