Span of Awareness, Scope of Operation (Responsibility)!!!!

These are terms and concepts that will become a normal wording when defining the new paradigms in Operational Experience of the “Distributed Multi Point Operational Landscapes”.

Two weeks I posted “The Changing Landscape of Supervisory System from HMI, CCR to “Distributed Multi Point Operational Landscapes”, and there was a significant interest, and questions (on email as normal), so I thought I continue to answer some of the topics.  For the last couple of weeks I have been involved in a number of projects that these concepts are having to sorted and defined, in order to complete the design.

So let’s clarify what we mean:

Span of Awareness:

Span of Awareness is relative to what a user / worker is exposed to, this means through the device (control room, mobile phone, tablet, remote station etc) and notification systems he is logged on too, now that the systems are becoming “self-aware”.  Traditionally the worker has only been aware of the equipment and process states that his UI could show but today this is changing to a worker/ member of the “operational team” being notified when the situation of the process is in an abnormal state, and the worker could contribute to resolution.

The concept of “always being connected” now applies to the industrial landscape, and with virtual operational team members being key to modern actionable decision chain.

Scope of Operation (Responsibility):

Scope of responsibility relates to what a work is assign, what “activities” that fall under the workers responsibility at this time. Based upon location, what the worker logs onto, or passed what activities (tasks) to perform, the system must be aware, and provide the worker with first up awareness, and then responsibility. Key is workers, responsibility and activities can vary from day to day, the system must handle this. Scope of Responsibility is very important when managing alarms, as the initial response needs to assigned to the correct user, this maybe not a station.

This is a new dynamic in the distributed supervisory solutions, where the no longer can you design responsibility of control to a station, as what is a station? A responsible user could be on a mobile devices, logon to a fixed station in the system, and drill into a situation and take an action, but that station could not at the location, or temporarily manned.

Example:

This concept is so important with alarms. Let’s take an “unconventional “Gas field” where we can have a compressor station (which there can 100s) with a local supervisory station, but this station will on be “sometimes manned”, as required for local operations. Now traditionally systems would have designed so all alarms from the compressor station would go to that station. But that is no longer valid, as no one maybe at the station, so the system must be aware if the station is manned, and who has current operational control responsibility for that station. This could be the overall IOC (Integrated Operation Center) or a particular user who maybe be driving between sites, and will connected by a mobile device, he would get notified and take action, which maybe logon at the closest station and take actions on whatever compressor station had the alarm.

This is a dynamic environment where responsibility of control changes between people, and how they interact with the system.  This leads to the design requirement I outlined for alarms two weeks ago.

 Management of alarms: it is essential for safety, legal, environmental and health requirements that new alarms animate, suppress/shelve, annunciate and trigger display changes only at the point(s) of operation, and only the workers using the point(s) of operation can acknowledge or silence new alarms. This means all alarms from asset to process, operational, but scope of alarm responsibility is aligned with span of operation (responsibility) but as a team there are “no blind spots” and alarm, situational awareness is escalated based on responsiveness, and situation. Assumption of control, and someone doing something must be removed.

The last statement is very important, when you have a dynamic operational team, you must avoid “blind spots” and if in the above example the responsible worker did not respond to alarm in a given time, or the situation gets worse, the system must escalate automatically to the next level, avoiding un awareness, and managed situation becoming critical.

The other concept introduced two weeks ago was the “assignment of Operation”, it is important due changing situation that operational responsibility of an asset can be changed to a more suited worker. Example above if I knew as the remote worker that I was going to drive to next station and I would lose connectivity I would pass control back to IOC, but I would not leave the current station and connectivity until the IOC “accepted” responsibility, and was aware that they now have responsibility for that area, and the system will expect alerts, alarms to action-ed from the IOC.   

Assignment of operation: an authorized worker must have an easy and reliable means to assign and adjust the spans of operation. 

Again I refer to the diagram below, that of the Flexible Operational team and how they will work together, avoiding “blind spots” and providing team work that will enable the fastest actionable decision and resolution. 

Over the last couple of weeks as I view designs I see people applying traditional thinking, a modern system may be distributed for high availability, and isolation control, but they are still apart of one operational platform. Where operational work, events, and situational awareness of the whole system is managed as a team.

Are you building this into your design?