Monday, November 21, 2016

What is the problems with much of the engineering literature?

With the increasing pressure on academics to publish articles and the many journals available for such publication I have noticed that many academic publication show clear evidence of a lag of industrial experience among the writers. The result - in my view - is, that many academic articles don't have a clear focus on the potential reader.

The following quote is from an Elsevier peer reviewed publication:
"In a large process plant, there may be as many as 1500 process variables observed every few seconds leading to information overload."
You may ask, what is wrong here? The writer appear lag a) an understanding of how a DCS works, and b) an the difference between logging data and observing them. It is true, that a modern DCS or SCADA may have 1500 process variables, which are being logged every few seconds. However, even at very complex facilities the operator usually have less than a dozen key process variables, which she or he monitors continuously. So - in my view - the statement that the number of variables entering the DSC or SCADA leads to information overload is incorrect and misleading. I think the reviewer should asked the authors to a least modify this sentence in introduction. Unfortunately most reviewers don't go into such details. I think this is a major quality issue with the current system of academic publications.

This very well illustrate a problem with current engieneering literature in the sciences. The readers and the authors see things from different perspectives. By Chylld - Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=13397795
I have however noticed, that the introduction to articles in the medical literature often are much more precise and to the point. In the engineering literature I find most introductions very loose essay like motivations for the work done after the work was performed.

Here is a second quite from the same publication:

"Using MFM to model the plant all that is needed is a basic understanding of chemical unit operations, their purposes and the fundamentals on which these purposes are bult, i.e. transport phenomena, thermodynamics and kinetics. This means that functional HAZOP study may be performed by less experienced personnel."
Unfortunately one of my publications is quoted to support this statement. However, the major problem in this quote is the assumption, that if you understand chemical unit operations, then you also understand how they may fail, which is what is needed for a HAZOP study. But operational principles of chemical unit operations are much easier to grasp than the failure modes of even a single unit operation, e.g. a distillation tower. In my article we only claimed, that a less experienced engineer could help with the pre-meeting tasks, if one divided the plant along functional lines. A distillation column would e.g. be divided into a reflux loop, a reboiler loop, a feed section and two separation sections.

Another area, where much engineering literature fails, is in comparing a presented approach or methodology to other approaches or methodologies for handling the same problem. This naturally leads to weak conclusions, such as the following:
"The results show the strength of this approach and can be considered as a useful strategy for dealing  with  complex  chemical processes."
However, the article contain no quantification of "the strength of this approach" or of  how "useful" the strategy is compared to what is already being done in practice. The result is, that practicing engineers, whether in design or operations or process control, are very reluctant in adopting new methodologies. This means progress is slow to move from academic research in engineering to engineering practice.

The question is if we can ever get both the readers and the authors on the same level. By Original image by Algr.Recreated, fixed isometric projection and vectorised by Icey. - Own work.This vector image was created with Inkscape., CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=1061744

So how do we get academic writers to focus more on their potential readers? Their audience! The current system provides no credit for number of readers to the authors. However, with the increasing number of open access online journals is should be relative easy for publisher to monitor which articles are being read more than others, and this information could then be feed back in the academic merit system. Currently such information about readers is only available through independent portals such as ResearchGate and others.

Friday, October 21, 2016

Why do you have too many alarms?

These days it happens several time every month, that I receive emails from ABB or GE about their offerings in the area of SCADA systems. I have started wondering if the decision about which SCADA systems to buy has moved from the engineers and operators, who will use it in their day to day work, to the supply department, just like buying paper for the photocopier/printer or coffee for the office coffee-machine. The latest email from GE had a link to their so-called blog shown below:
This made me think: Why is it, that we have too many alarms in our chemical plants and refineries today?

When I worked at a major facility in Sarnia many years ago, the process engineers in charge of the plant had an alarm policy, which among other things stated, that if you implemented an alarm, then you needed to specify what action you wanted the operator to take, when that alarm came in. The result was, that our Honeywell process control system only generated 2-3 alarms every hour on most days, and that it took the process engineer just a few minutes to scan the alarm log from the night shift.

To be fair to today's plant and control engineers we also were two control engineers to ensure, that the process control system did control the plant most of the time. Great efforts were taken to maintain the basic flow-, level- and temperature-control loops as well as the supervisory loops on cracking furnaces or a distillation towers. My guess is, that today this manpower has been significantly reduced, and hence the basic and supervisory control loops are not as well tuned as 30 years ago.That is a shame! Because without a well tuned set of basic control loops any attempt to implement a unit wide model based control, such as MPC, to operate the facility as close to a constraint as possible will most likely fail.
Because of our well tuned supervisory control loops the facility did not implement MPC until the mid nineties - many years after I left. However, when those MPC's were finally implemented they were equipped with operator displays based on our experience from the supervisory control loops. This meant, that the operator decided which constraint the MPC should take into account, and that the operator could see which contraints were active. That transparency made the MPC's a huge success - even with the mentioned manpower reductions.

I am certain Alicia Bowers, who wrote the blog for GE, is an intelligent writer, but I don't buy her suggestions, that the many alarms can be handled by
  • Using analysis tools to reduce the number of alarms that occur.
  • Drive response on the alarms that matter.
  • Leverage HMI/SCADA design best practices.
I think a more fundamental look at who and what decides when and where an alarm is implemented is needed together with a look at the tuning of the basic control loops. After all most alarms are properly implemented to notify the operator about a deviation, which the basic control loop is unable to cope with. So let us go back to basics:
  • Tune your basic control loops well. This can take time. I recall one of our instrument engineers spending several weeks tuning our polyethylene reactor temperature control loop.
  • Implement only alarms for which a specific operator action can be identified. This properly require input from experienced operators.
When that is done, then consider providing the operator with displays that are consistently designed either according to best practices such as defined e.g. by the Abnormal Situation Management Consortium or by a company display design guideline.

And now about the question in the title of the blog. I think the many alarms that many operators have to copy with is a result of it being to easy to implement alarms in a modern SCADA system. For example it is not uncommon for a supplier of a pump to request and get implemented several dozen alarms on a simple large pump. Most if not all of these alarms are irrelevant for the operator during day to day operations, and in my view should never be implemented as alarms. These pump related events are relevant for maintenance of the pump, and hence should just be logged to an event file, which the maintenance engineer could then review and take action on.

One approach to limit the number of alarms implemented on a SCADA system would be to simply require, that all new alarms are subject to a MOC review - even those implemented during a project. After all most SCADA systems don't come with any alarms preconfigured. So the implementation of an alarm is a change to the SCADA system, which should be subject to MOC review.