Why monitoring is, giving away to exception based ”Self Aware” philosophies?

Over a year, ago I jointly authored a whitepaper with leading thought leaders at Shell on the future of oil and gas field systems

“Establishing a Digital Oil Field data architecture suitable for current and foreseeable business requirements”.

The paper raised a number of concepts one of them, the need to move away from monitoring to exception based philosophies in the operational system. Over the last 2 weeks discussing with industry thought leaders in oil and gas, power, infrastructure and mining, the growth in data from the field through smart devices is accelerating the shift to a “self aware” / exception based systems. It has been fascinating to see how in a year the increased realization of a different approach to operational experiences to be able to enable effective decisions and actions. As the shift to exception base systems brings in concepts such as:

• “Self Aware” entities that will either be in the smart device, or higher level if it a smart process that can detect conditions and trigger notifications and operational procedures and awareness
• Advanced Process Graphics: the shift to uncomplicated view and easily identification.
• Situational Awareness: the ability to focus understand, associate related knowledge to rapid decisions and effective actions.

The paper centered on Digital Fields, but the principles apply across industries:
“Another key instrumentation requirement is to report by exception, i.e. Sensors to have a remotely configurable ability to detect and report changes. This approach will minimize source data flows and as much as possible distribute intelligence to the lowest possible level and thus minimize data volumes/complexity in PAS and higher level systems.

For example, consider a well head pressure transmitter. With this approach,  the transmitter will be smart enough to recognize and report only changes greater than say one percent, however, an authorized user should be able to remotely change the reporting threshold, to say .5% if so required. Compare this to the current approach where all data flows through PAS systems to historians which, ironically, store large volumes by filtering data in a similar manner. Hence the virtue of filtering at source, minimizing data transfer volumes and minimizing data storage in higher level systems. Note, exception reporting at source applies to analog and vector/matrix parameters - digital parameters naturally report by exception.”

The above extract from the paper outlines the concept, and why, the essential item is that monitoring is not practical as the data levels exponentially increase from the field. We need to reduce data on networks especially over distributed networks, and by going to local detection and “self analysis” will do this. The “self aware” approach will enable local detection of a condition that is escalated to operational people who can drill down, and draw on local data as needed. This approach also means intelligence is local or close to the source. How real is this? Last week an opportunity came to me where a gas well head will have all it is instrumentation and control on the well, and there will be a web server/ service on this well, and there will be a wireless 3G connection. A follow on discussion was at what level in the architecture would this detection be, it should be as a low as possible, down in instrument, controllers, but also discussion about “smart/ intelligent” processes, and process units deployed at the Operational/ supervisory platform layer of the architecture bringing together information, data from multiple sources and taking exception.

The above diagram shows the concept of smart process well, more than a data structure, and why a data centric architecture on historians will not be satisfactory. There is a need for an “Operational Application Platform” that enables smart “living” entities that can be distributed across an industrial landscape, and managed as standards. Feeding into local data storage systems, but doing more, by trigger exceptions, events, and executing escalation and awareness across the operational team, so enable alignment and responsiveness in this every growing operational environment.

I will expand on the "Operational Application Platform" vs the "Enterprise/ Data centric Historian " strategies both are valid, but in different uses, and there seems to be some confusion.

The Changing Execution of Flexible Operational Team

“What does Operational Collaboration Mean for my Modern Supervisory System?”

Last week I travelled to Western Australia, a state where there is a significant mining boom, and a challenge of how to operate it’s plants with a 3 way changing market:

·          The need to be agile to maximize production, which drives a push towards streamlining  “Value Generating Assets”.

·          The shortage of skill sets and experience

·          The changing demographic of the workforce to a younger more “digitally native” aware personal

As I spoke with people in the industry from engineering to operations, the topics I have been discussing in this blog over the last couple of months were confirmed. It does require a different thinking on how to put a system together, and not just different technologies but also an awareness in the design of the system of the constraints these new dynamics bring. This is calling for a rethink of operational practices and collaboration in real-time, to enable the “Flexible Operational Team Work” required, this goes beyond “Operational Centers” it is a new level teamwork, which will require a new thought pattern when designing the operational systems.