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?  

Effective Situational Awareness (Actionable Decisions) requires “Engineers to evolve to Artists.”

Industrial situational Awareness is a key concept for the future of supervisory/ operational systems. Moving beyond ASM (abnormal situational Management standards) which have had mixed success, not due to standard, but due to implementations. Understanding this subtle difference in implementation is when we start talking “engineers evolving to an artistic, human factor aware.”

This image shows a traditional process screen with photo like images, and the right hand image shows the intensity of eye focus based upon color and drawings. The issue is the awareness of the alarms up the top or indication symbols up the top are lost, this is where the ASM brings a cleaner view, as seen in the image below where this same screen has been evolved to ASM. Yet even that design can be improved.

Last week we had the Australian User Conference combining old Invensys and Schneider Electric, many productive discussions. However, one that stood out was with a college Rik De Smet around the effective situational awareness. Rik like me has been involved in a number of operational centers most notably one in Oman across 70 existing DCS systems . Where the project applied ASM (Abnormal Situational Management concepts) but derived from human factor experts in Holland, where they looked not just the effect of grey, but went well beyond into understanding the tracking of a user’s eye. The results drove screen layout, color and application of awareness.

The conversations last week went beyond this, to the fact that now many companies have released ASM based graphic libraries, and how many engineers are applying them without the full thought. Yes, it brings improved results, by de-cluttering the experience, but there is another level of operational value. It has been proven in upstream oil and gas, transportation, mining that well applied “situational awareness” (ASM) applied at graphics, and alarms regularly provides 30 to 40 % improvement in awareness and responsiveness over traditional screens with photo generic and many colors.  

Rik has been taking this to a new level with tools to evaluate engineered screens and to see where the focus is, and to provide feedback to designer. These tools, track the eye focus and intensity of eye focus (distraction) to a spot or image. Providing valuable feedback for the designer to adjust the layout and effect. With good examples of what appeared to be an effective ASM type screen, with some managed tools taking into account “human factor.” A heat map showing that same screen with actual eye focus, and it was clear that tuning was required in order to gain that early awareness that was expected.

This image is now showing a typical ASM screen applying standards in ASM, and alarm borders around critical equipment. Many people would be satisfied with this, but when you now apply the eye intensity tool, to that same screen, you do see focus on the critical equipment in the middle. But you also see a loss in focus to the bottom, navigation buttons and even company logo, all of which are not important in awareness of the plant state.

This insight brought a new level of true “human factor” and effective “artistic” side to play in the design, to enable a step up in results to the next level of value. For me, it brought reality to a factor I suspected that the system engineers going forward from today, need extra tools, or someone in the project requires the expertise. There are online human factor tools coming available, and these services will become vital in the next few years.

We combine this “early awareness” to enable decisions, but the real requirement is to go to “actionable decisions” that empower the user to lead to a decisions, and action very rapidly that is a best operational practice. In another conversation my mind went back to Hudson River plane landing, where the pilots did not speak for 3 minutes, that took roles, made decisions, and action ed out well trained operational procedures that enabled rapid success. The two pilots had not met prior to that take off, but they were able to combine to execute. The only way we can bring this into industry through the changing of operational approach, embedding experience and process, so we do not just enable decisions, but “actionable decisions.”

Resetting the Way we do Automation/ Operational Projects!

A couple of weeks ago I talked about the 3^rdgeneration MES and the shift to “model driven” in order to absorb change in the operational practices and this drives the shift to develop standards and roll them across plants as well the elimination of custom code.

 Again last week the realization that we need as engineering, and IT that we need to rethink the approach came through in discussions with 2 customers. The discussion really happened around two items:

1/ The speed at which projects in the automation world / operations world need to happen, it is halving as one plant engineering manager point it out. But in his second breath he stated that they no longer stable e.g. you can be sure that the business will drive operational change that will require that project to evolved twice in 12 months.

The discussion was interesting as one of the two in the discussion had grown up in the same environment as I and reflected on the fact that projects use to take a year, they were significant and they stayed in a stable condition for 5 years, this was the basic rule I also found when in Europe and Middle East in the 80s/90s.

2/  The second was the scope of responsibility and rollout, they both commented how they use to be in charge of a team that looked over one to 2 plants, now they run projects that span multiple sites often going outside the country.  The expectation is that the same capability will roll out over multiple sites at a decreasing cost, and decreased time to production. The same changes in the following 12 months must be rolled out, as well.

Combine this with the more complex projects as the level 2 and level 3 merge in the traditional automation levels, the traditional approach to project management and project evolution are not valid.

At the ARC conference in Orlando in February, this same message was echoed by leaders from Exxon, GM< and Nestle.

Sandy Vassar, Facilities I&E Manager, ExxonMobil Development Company used the phrase "it just happens" to indicate his team's goal for the automation portion in each of the more than 100 oil and gas projects now in various stages of planning and execution at the company.

He believes the industry needs "lean project execution," that separates the physical system from the software. Toward this end, the technology suppliers have to think differently and deliver technology in a way that allows the team to eliminate, simplify, and/or automate steps in the overall execution of automation.

He listed the top twelve challenges:

1. Eliminate, simplify, and or automate steps in the overall execution of automation

2. Minimize customer engineering and reduce the total amount of engineering

3. Shift the custom engineering to the software and rely on standard hardware components; progress hardware fabrication independent of software, design

4. Virtualize the hardware and prove the software design against the virtualized system

5. Prevent design recycle and hardware/software rework

6. Eliminate unnecessary automation components and standardize the remaining components so all systems look alike across projects

7. Eliminate or minimize the physical, data, and schedule dependencies with other disciplines

8. Simplify the configuration of interfaces with third-party packages

9. More easily accommodate changes, including late changes

10. Mitigate the effects of hardware and software version changes

11. Eliminate, simplify, and/or automate generation of required documentation

12. Challenge traditional approaches

None of this is unique or new, but like the conversations last week this forum confirmed that a “rethink” is needed, and cultural change. It is important to realize while product vendors must evolve more and more to provide platforms for reuse, and management of standards which provide and en environment for the capture of “Unique Operational Practices”  in a configuration environment that allows evolution and reuse. The engineering community within the companies and within the System Integrator partners need to also evolve to a more agile approach to projects. Compared with the traditional project approach of my site is unique and doing things in a 100% custom way.

The new generation will expect things in a shorter time and will compromise uniqueness for speed and agility! One leading company produced this diagram when they looked at their multi site projects in automation, and it is telling.

I doubt there is no argument on the outcomes, the graphs show 4 key findings (principles):

1/ Integration: across different PLCs and systems, across sites so there is one namespace, one alarms one history one abstraction platform. But integration must be trustworthy and sustainable.

2/ OO Object Orientated supervisory: This is key to have an object/ managed software approach with templates and management of standards at the supervisory and operational level. Key to providing consistent plant model, consistent information, and consistent experience in UI and action as well a platform for the evolution of the system over time.

3/ASM for UI and Alarms: the move to exception based awareness, vs monitoring.

4/ PLC Blocks: again to enable management and standards to allow absorption of change.

This is not new, yet I only see a few companies truly implementing new solutions in this way, which leaves me to ask how will the others deliver systems for the current and future “dynamic world”? 

Is the Transition to Gen Y so Significant in the Industrial Environment?

This question was put to me by a magazine editor in Czech Republic this week, he was from Gen Y (born after 1980), and he was commenting after one of my presentations.  This is not the first time I have asked “do you genuinely think the transition to Gen Y will be that significant?” It is truly valid challenge, so I decided I needed answer why I believe it is a significant milestone or transition in the operational approach or culture in the Industrial Market.

As he asked the question he was texting and recording the interview on a Samsung PDA, and he had prepared his questions well, by researching me on Linkedln, and reading this blog. To him this was a natural way of doing research, yet an interviewer the week before from Gen X (early) had not done this research, he just had heard my presentation and asked questions based off this.

Yes, many of us from the  Bayboomer, Gen X generations have transitioned to living by our PDA, always “connected” and using email and text for communication, we do our research off Youtubes and forums, but while we transitioned it is not natural. We certainly do not share as well, yes some of us have Facebook accounts, but many do not. I asked a group of 120 people in the Gen X and Babyboomer generations how many had Facebook accounts it was less than 20%, but the small segment who were Gen Y had 100% with FaceBook accounts and all had contributed at least 1 you tube to public domain.

Gen Y has grown up in an environment where the internet is just a natural part of life, most would not remember a time without internet, and the same applied to mobiles that are used for more than voice. SMS texting comes before having an email account, where to Gen X we had email before Text, and tend to use email as the primary text communication vs SMS. The way Gen Y naturally searches on Google and filters the information and rapidly transverse the information to a desired result. They expect to use a map on PDA and see the closest banks, restaurants and other information. Wiki Pedia is a natural source of knowledge, and it is natural to contribute with comments, and material to Youtube and pedia style environments. The most significant transition of generation from Early Gen X and Babyboomer is the shorter time in a role and location, the willingness to transition their career more often. Remembering by 2020 the expectation is the average tenure in a role will be 2.4 years or fewer, people are expected to have at least 4 careers and over 20 jobs in these careers.

These are contributors to the transition, but given that many of the industrial supervisory and operational interfaces/ experiences created over the last 15 years, have been defined to control the process of a unit or equipment. Many are in isolation (islands of control) with limited inter application integration as the design was not done in a holistic view as the project had a deliverable goal and timeline. The navigation, and operations/ actions of the user interface had a fixed button navigation, and assumed a certain level of experience, and on how to use interface and control the process, this experience often came from training on the interface by the developer to the users.

Combining the holistic end to end operational control which requires multiple workers to run the system, often the operational stations are now transitional, so the workers will transition from one workstation to another executing the actions, the experience needs to be consistent to help smooth transition as they do their daily role, plus the ability to access the states elsewhere in the plant, based upon a notification they would have received maybe on a screen or mobile, and they require more detail than available on mobile, so they will drill in using a remote workstation. Now as the worker is executing his day, he is faced with a situation that is new to him, or requires some process experience, and he is unsure of the decision to take as he has only been in this plant 3 months. The operational interface requires for the user to collaborate with a remote expert on that process, sharing the situation, some screens and states, plus a live conversation, this should be natural in order to make a decision and take a correct action as soon as possible.

So when I talk about the significant evolution we going through in operational culture and approach, I am referring to the ability to maintain operational continuity while absorbing this constantly dynamic / rotating operational workforce with now limited experience in a role and location.

The growth in operational programs that are looking re-engineering their supervisory (HMI) systems, and operational interfaces to provide:

• Consistency of operational experience across workstations and devices
• Natural Collaboration with others of more experience or in the operational team.
• Multi workstation and mobile devices on a common system that interact
• The natural learning, and knowledge management and access
• Consistency in operational actions across workstations, devices and processes
• The shift to exception based operational control, using the ASM (abnormal Situation Management concepts) for faster recognition and action on the situation.

Is confirmation that it is not a technology upgrade only it is an operational culture approach that is driving the expectation significant increase operational agility?

Is your supervisory/ plant operational system ready to absorb a dynamic workforce, while maintain operational continuity in the agile world of increased new product introduction, and competitive pressures.

I would be interested in people’s comments.