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”? 

Standards What do they mean?, What does it take?

As we evolve the Enterprise Control capability around multi-site and system, (yes distributed system), I have been out talking to people. A common topic is standards, the more architectures try to unify/ standardize process, operations etc., the more standards apply, but they have been round for years in control blocks. But why is it such a struggle at the supervisory level, and MES? Basically it appears to be:

·         Defining what is a standard? and Why make it a standard?

·         Governance and investment to make a standard but the much big investment to maintain and evolve the standard, it must be justified.

·         But at the core is this mis understanding that standards are like “applications”, when that are closer to “products”.

The whole concept of Enterprise Control is based on the ability to Federate and Empower Operational Workers, this can only be done if there is a consistency in operational execution, requiring standards. So we are committed to a significant investment evolving the enterprise capability especially around creating and maintaining standards.

Standards provide the advantages of:

·         Application reuse

·         Faster project time to Value

·         Reduced risk and errors

·         Reduced commissioning time

·         Provide consistency of experience, operations, control etc across applications

·         Etc

A standard is anything you want to reuse and duplicate across multiple situations. This could be symbols, documents, recipes, workflows, reports, data structures, objects, control strategies, on goes the list. But it is important to understand a STANDARD is like a PRODUCT, vs an APPLICATION, they are valuable as long as they are useful standards. As one customer said

"We are good at building standards in control, and supervisory, but useless at maintaining them so we go from one standatndard to many versions of these applocations now way to maintain."

When I quote this to many customers I get a nodd of heads, and I thought a great debate a week ago was a set of top technology executives at one company really asked the question where and what is a standard, realizing success  is based upon them, but only is if they get alignment on what they are and investment required for them to succeed.

This means standards must evolve, with new capabilities, and they will have issues so must issue tracking and fixing, so that each new version has new improvements, and fixes. This requires governance and systems to track feedback and issues against each standard, and then planning of the next versions. This is closer aligned to product governance/ lifecycle than an application/ project culture, this is probably the biggest issue we see is most companies fail to recognize the investment in governance and management of standards. This causes the standards too very quickly become un usable and not valuable, so adoption drops off.

Also the products you are applying the standards to must understand standards and templates, which a lot of tradition products do not. While ArchestrA was built on the concept of REUSE and templates, we are fully committed to evolving the standards management and governance to help sustain and evolve standards across sites/ multiple applications, and extend this capability to the other aspects of the portfolio which make up the solution. The “day in the life” in the life of standards the jobs to be done, and experience is being evolved based upon our product lifecycle experience combined with a number of customers who are apply standards, and have implemented governance.

Customers/ Sis start by building a understanding on how they will make the standards succeed, the investment in both culture/ technology and process will return significant. We hope we will continue to evolve to make this evolution to reuse of standards across enterprises a natural act. Your feedback on how you are using standards, or plans and evolution input is appreciated to tim.sowell@invensys.com.