Collaboration with plants and Governance is key to Standards,

There can' t be a week go past that companies do not talk to me about standards leading rapidly to discussion on standards management. Standards are the only way companies can achieve:

1/ Rapid roll out of new processes across plants

2/ Reduced risk

3/ Reduced dependency on key critical experienced resources.

4/ Consistency in operations, information across plants

Yet most companies do not really understand what a standard is and the investment, design, and approached needed so that the standard can evolve over time, and be sustained as a standard.

When you have comments like;

 "You that standards library we built? We now have 45 of them ones for each site."

Losing the whole effect of what a standard is and hamstringing the ability to evolve and react to the market in an agile way.

The culture of a standard is closer to that of “a product" than an “application" yet most companies treat them as an applications. Missing the culture and governance needed to make the standards grow and be naturally adopted.

Culture:

Too often we see it as push from the Center out, with the standards being designed in isolation of the plants, or certainly that is the perception from the plants.

The key is to have a culture where the standards and built with the first site, but with a mind that it will be rolled out across plants. So the design, architecture and approach allow for future capability to be added to it.  Providing the plant teams the ability to contribute, and feeling like they have some ownership, so they will adopt. Plus the culture that sites engineers can contribute improvements back the central governance and improvements will happen.

  

Governance:

Clear ownership of standards management, this could be or multiple people with different aspects of the standard library being managed by different people. Similar to what we do with software products, we have product managers, who gather the feedback, define the vision, and strategy, and then provide direction for improvements from version to version. The same concept Product Management for the standards, listening interacting with the sites, determining what is common and valuable to standard by version. Then making sure there is clear governance process, enforcement in place, and testing of the standard.

Architecture levels:

It is important to have the correct standards and levels, so the Hierarchy levels need to set up, with the correct number so the appropriate changes can be added at the correct level. A good example is below where there are corporate, to site, to area, then plant, each of these allow extensions to that level while sustaining consistency from the top.

System Management over Level 3 (operation/ Automation Software)/ System Sustainability Grows as a Focus

We have seen “system management/ diagnostics/ health” coming for a while, and it is overdue the increasing focus on ISA Level 2 and Level 3 software sustainability and management, this means operational, and automation software. Including MES, OEE, Asset Utilization, historians, supervisory system, alarming systems, HMIs and device integration, out to quality management, and the other home grown systems that make up this un structured space. At the business applications, the business databases, back office applications and also at the PLC and DCS code, we have seen mature system management strategies and systems put in place. In this middle layer where there is no dominating player, and there is a lot of project centric applications, there is little defined strategy, or approach. Now with IT coming down and also the shift for more aligned systems, this area has come under an increasing spot light. Due to the realization that this area of level 2 and level 3 software working in unison, and reliable is key to successful “operational Effectiveness” of a company and plant.

In the last couple of weeks, I have been involved in a number of “HMI upgrades” (this was the term used in the project) discussions, but a closer look at who was driving the project it was not engineering, it was Operations. They are looking for changing their Operational empowerment and effectiveness through a cultural change (will talk this again next blog) but also through an alignment in operational actions, and decisions across teams, sites, and production runs. With less buffer in production, there is less room for delayed decisions or unplanned downtime or unnecessary down time. So these projects are not about upgrading HMI to the latest technology, they about evolution to a new operational approach, and with that to a platform that will enable:

·         Operational decisions faster

·         Operational decisions more consistently

·         Operational evolution and agility, through being able to add new functionality and evolve in a managed methodology, with standards, and governance

·         Operational continuity based upon system risk awareness and fast corrective actions

The discussions in all cases lead to the word of Governance on the implementation of application configuration, standards, and how this can be managed with versions, etc.

The second discussion was around running system and system management, understand the risk on software and hardware it is running now, and predicting risk so actions can be avoided.

At recent customer council in Europe with key customers both of these were raised as significant focuses for them, and that both must align with It practices while still enable uniqueness of the operational environment. Many are building or planning to build their own management systems.

This lines up with Invensys Soft ware’s focus on System Management with such initiatives:

• Proactiv: the remote monitoring of site software and feeding back issues to Invensys experts who will pro actively engage with partners and the site to take corrective action early.
• Software Asset Manager: which looks out over all the known systems on the site and identifies the Invensys software versions, patches state.
• License management: Again this is the central licensing management across actual PCs and virtual systems.

Also, we evolving the holistic approach to system diagnostics, and to enable ease of site monitoring and awareness, also aligning this with Microsoft System Central for larger sites.

It is key that all running software supply it’s state and instrumentation as a service in a consistent way, so it can be management and work no matter the vendor if customers are to build a sustainable system.  

Modularization Standards enable Fast Deployment and Minised Risk

This week I have met with many engineers from different companies in a number of industries. It is nice to see innovation and people pushing the limits. A company I met built modular solar power plants, and rolled them out over many sites. Due to this modular approach, like the physical plant, they just assemble these plant control, and operational systems. How can this be done with traditional automation systems with tags?

Standards have been talked about in the past, yet I continue to talk with people, and they really do not fully understand them, and value, but also the governance and culture which must go with them. This customer was different, and it was “breath of fresh air”, they saw value, they applied governance, and management.

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

·          Ability to manage evolutionary functionality over multiple sites

 

So what “governance/ culture” is needed? Firstly sitting down and really mapping out the common denominator on the templates what people require, it is better having fewer templates and fewer levels of derivation, but understanding the level, and how it will be applied. This customer has spent time defining and constantly understanding the role of template, the impact of change as they have now rolled this library out over 10 + sites and will roll it over many more, but since they are EPC where they deliver projects to different sites. They are constantly refining the standards, but understanding how they will rollout and impact existing sites, this requires a good capture of thinking why particular functions where added and how they have been used. Sound familiar as it is more a “product culture” than “application culture”! What I mean is that building an initial product and standard is one thing, but as soon as you start installing you have legacy and comes with this responsibility of evolving the existing and new applications. Too many people do not take this into account there are needs for a culture of capturing the requirements for enhancing a standard, from many sites, and then planning version up grades to the standard, the same as a product.

The diagram below shows how Kumba mining has derived their standards:

They have a clear tree understanding the derived impact, alos when they built the core standards they tried to reduce the amount of types. We are now looking at how set up standards in a polymorphic manner that will have has many functions as needed in the base template, but the user has the ability to select the required functions, there by turning on the required capability and adding it to the template. This means as the standard evolves functions are at core, highest level, avoiding lots of different yet very similar standards. The reason for this might not initially be apparent, but as you rollout with many variations understanding the impact across sites, it will be hard if you do not control the amount of standards and variations. A basic rule should be “once something is added it should be sustained” this core principle of object orientated systems. Freedom is not always the best advantage, and putting in place a culture of someone owning the standards who then listens to the requirements and decides if that capability will be added at the highest level or what level is key. As we develop a “Corperate Standards Management” capability to ArchestrA, initially people have asked for a product, yes we will provide a capability to help manage standards across sites, but I am becoming less convinced that it should be a product vs a “Software as Service”, where the service is providing the product management skill as a service. This especially become important when you consider standards are not just automation objects or control strategies, as you move to managed operational system they will involve many types of standards, like reports, layouts, symbols, KPIS, materials, reason  codes etc.

Having one culture, one approach over all products and standards, will enable sustainability. So do companies and sites expect to have this expertise and culture, or will this “outsourced” even if the standards repository is maintained within the company, certainly we have seen this happen on some initial multi site systems.

I would be interest in your feedback.

 

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.