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.