Many experienced designers do not even consider troubleshooting plant operation as part of their job. The article argues that contrary to this notion, troubleshooting is a challenge which may lead to a quantum leap in the plant design and operation quality.
Desalination plant operation is safe-guarded by warnings and alarms. For the plant of over 100 MLD their quantity surpasses 15000!
An operator warning or alarm is just a part of operation exception answering WHERE and WHAT questions - where the abnormal operation happens and what is considered abnormal.
Exception is useless without the HOW part - what is wrong and how to return the operation back to normal.
The HOW part - troubleshooting - is still missing in modern desalination mega-plants because of a shear amount of manual work to be done: every warning or alarm shall point to some pair of cause – remedy descriptions. The cost of it is delays and mistakes in operator corrective actions. (In 2007 the operator mistake in the start-up procedure of the desalination plant destroyed over 1500 reverse osmosis membranes, total damage being over US$1 million.)
It is considered a process engineer responsibility to collect the troubleshooting recipes from the Original Equipment Manufacturer (OEM) manuals and translate them into practical steps tied to existing instrumentation - the basis for control software programming. (It hardly happens because process engineers are not in the habit of reading the O&M manuals.)
In practice roughly 50% of OEM recipes do not fit into remotely operated automatic plants; different instrumentation is needed (to say nothing about the language of explanation). In other words, troubleshooting requirements change the plant design.
What makes the HOW part even more difficult is lack of synchronization between software programming timing and the troubleshooting information availability.
We must admit that conventional engineering failed to move to recipe- or rule-driven troubleshooting required by ISA-18.2 and IEC-62682. Instead, it heavily relies on experienced operators who understand the process well enough to know when there is a problem and how to react to it.
In times when mega-plants turn into big data factories connected to cloud, and rapidly move to predictive AI-driven maintenance, the operator experience stops being an asset. It is not sharable and it does not absorb any more growing automation complexity and sophistication.
The operator experience does not allow closing the feedback loop leading to self-improving ecosystems of plant owners, designers and equipment suppliers. In such ecosystems every new troubleshooting recipe is immediately shared between stakeholders and plants.
What holds back the conventional engineering from building troubleshooting framework targeting Industry 4.0 is a missing fundamental entity - new level of engineering information abstraction offered by digital engineering. It relates to conventional one in the same way as modern programming languages to Assembler (1951) based on the machine code instructions.
As crenger.com experience shows, this level turns any plant into customization of some universal design. In our case, the same troubleshooting abstraction (written once) is auto-applied to matching equipment pieces and systems infinitely. So it does not matter how many alarms the plant includes.
Matching is not complete if the associated equipment piece (or subsystem) neither is equipped with the needed instrumentation nor emits the required alarm. In other words, troubleshooting management framework is part of the design auto-validation.
The user interface for handling troubleshooting data (of PlantDesigner software) is shown below. Window 1 sets 3 different levels of the device abstraction from generic one described by keywords, to real-life product. Window 3 links the same cause-remedy pair to different generic events. Window 4 is for optional operation description of the process module containing the device.
Crenger.com makes troubleshooting information part of the product technical offer submitted online by OEM. The offer is considered not complete, if troubleshooting is skipped.