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

 

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